我已经写了,而我的Ruby代码的测试,但作为一个前端开发者,我在把这个为我写我的前端代码的代码明显兴趣。 还有就是我一直在玩弄相当多的不同的选项:
- CasperJS
- 水豚和Rspec的
- 茉莉花
- 黄瓜或只是Rspec的
什么是使用测试的人吗? 而比进一步人们有什么样测试? 只是JavaScript的? 链接? 形式? 硬编码的内容?
任何想法,将不胜感激。
我已经写了,而我的Ruby代码的测试,但作为一个前端开发者,我在把这个为我写我的前端代码的代码明显兴趣。 还有就是我一直在玩弄相当多的不同的选项:
什么是使用测试的人吗? 而比进一步人们有什么样测试? 只是JavaScript的? 链接? 形式? 硬编码的内容?
任何想法,将不胜感激。
我在几个月前有同样的问题,并谈论许多开发商,做了很多的研究,这是我发现了什么。 你应该单元测试你的JavaScript,写一小部分UI集成测试,避免记录和回放测试工具。 让我来解释更多的细节。
首先,考虑测试金字塔 。 这是麦克·科恩创造了一个有趣的比喻,这将帮助你决定你应该做哪一种测试。 在金字塔的底部是单元测试,它们是固体,并提供快速的反馈。 这些应该是你的测试策略的基础,从而占据金字塔中最大的一部分。 在顶部,你有UI测试。 这些都是与你的UI直接交互,如硒确实例如测试。 虽然这些测试可以帮助你发现错误,他们更加昂贵,并且提供了非常缓慢的反馈。 此外,根据你所使用的工具,他们变得很脆,你最终会花费更多的时间来维护这些测试比编写实际的生产代码。 服务层,中间,包括不需要UI集成测试。 在Rails中,例如,你会直接测试,而不是与DOM元素交互的REST接口。
现在,回到你的问题。 我发现我可以很大,仅仅通过对JS编写足够的单元测试减少在我的项目,这是与吨的JavaScript编写的Spring Roo(Java)的Web应用程序漏洞的数量。 在我的应用程序,有很多写在JS的逻辑,那就是我在这里测试之类的话。 我不关心页面是如何将实际看,或者如果动画播放,因为他们应该。 我测试,如果我在JS写模块将执行预期的逻辑,如果元素类被正确地分配,并且如果错误状况是公处理。 在这些测试中,我一直在使用茉莉花。 这是一个伟大的工具。 这是非常简单易学,具有良好的嘲讽能力,这是所谓的间谍。 茉莉花,jQuery的 ,如果你正在使用jQuery增加了更多强大的功能。 特别是,它允许你指定固定装置,这是HTML代码的片段,这样你就不必手动嘲笑DOM。 我已经集成了Maven的这个工具,这些测试是我的CI战略的一部分。
你必须要小心的UI测试,特别是如果你依赖记录/回放工具,如硒。 由于UI经常变化,这些测试不断打破,你会花很多时间找出如果测试失败真的,或者如果他们只是过时。 此外,他们不添加尽可能多的价值作为单元测试。 因为他们需要一个集成的环境下运行,你会大多喜欢运行它们只有在你完成开发,当固定的东西成本较高。
对于烟/回归测试,不过,UI测试是非常有用的。 如果你需要自动完成这些,那么你应该注意一些危险。 写你的测试,不记录他们 。 记录测试通常依赖于你对你的代码做的每一点变化打破自动生成的XPath。 我认为,黄瓜是用于编写这些测试,你可以沿着用它来与webdriver的自动执行浏览器交互一个良好的框架。 代码想着测试 。 在UI测试,你将不得不作出元素更容易找到,所以你不必依赖于复杂的XPath。 添加class和id的元素,你通常不会将频繁。 不要写每个小角落的情况下测试。 这些测试是编写和花费太长的时间来运行昂贵。 你应该专注于探索你的大部分功能的情况下。 如果你在这个水平了太多的测试,你可能会测试你以前在单元测试中测试(假设你已经写他们)相同的功能。
在我目前的项目我使用斯波克和盖布写的UI测试。 我发现这些工具惊人。 都写在Groovy中,这适合我更好的Java项目。
有很多的选择和工具这一点。 但他们的选择取决于你是否有一个网络界面或者它是一个桌面应用程序?
从你提到它的工具假定的Web UI。 我建议硒(又名的webdriver): http://seleniumhq.org/docs/
有各种语言的支持(Ruby是在列表中)。 它可以针对各种浏览器中运行,广告它很容易,有很多教程和使用技巧的使用。 哦,它是免费的,当然:)
不过,我觉得作为这个帖子得到了很多喜欢的,我想我的答案张贴到我的问题,我现在要做的编写大量的测试和如何测试前端现在已经转移了很多。
所以在FE测试方面,我用花很多时间因缘与茉莉花 ,虽然karma将与其他测试套件像摩卡&qunit很好地工作。 虽然这些都是伟大的和因果报应,您可以直接与浏览器界面运行你的测试。 缺点是作为测试套件变大它会非常慢。
所以最近我已经搬到开玩笑这是更快,如果你的写作反应的应用程序,使用酶与快照测试给你真正的好报道。 覆盖玩笑的说到有伊斯坦布尔覆盖内置的,建立和嘲讽是很容易使用简单。 缺点它不浏览器中测试和使用的东西把它称为jsdom这是快,但也有一些滋扰。 我个人当我经历的WebPack /通天编译我的代码不特别觉得这是一个大问题,这意味着跨浏览器的漏洞是相当稀少,所以一般不会,如果你手工测试反正一个问题(和海事组织你应该)。
在轨道内工作方面现在栈,这多方便了webpacker宝石现在可以使用NPM和节点通常是更除外。 我会建议使用NVM来管理您的节点版本
虽然这不是严格的测试,我也建议使用掉毛,因为这也拿起代码中的很多问题。 对于JS我用eslint用漂亮和SCSS / CSS我用stylelint
在什么测试,我认为卡洛斯谈到了测试金字塔仍然是相关的,毕竟理论并没有改变,只是工具。 我还要补充约为测试实践,我总是考,但到什么水平和覆盖范围将取决于该项目。 它来管理你的时间和花费几个小时/天测试生命周期短的项目是非常重要的。 大型/长期项目更大的测试套件的好处是显然更大。
无论如何,我希望帮助人们看问题。