前端测试:测试什么以及如何测试，使用什么工具? [英] Frontend testing: what and how to test, and what tool to use?
问题描述
我为我的 Ruby 代码编写测试已经有一段时间了，但作为一名前端开发人员，我显然有兴趣将它带入我为前端代码编写的代码中.我一直在玩很多不同的选择:
I have been writing tests for my Ruby code for a while, but as a frontend developer I am obviously interested in bring this into the code I write for my frontend code. There is quite a few different options which I have been playing around with:
人们使用什么进行测试?除此之外，人们还测试什么?只是 JavaScript?链接?形式?硬编码内容?
What are people using for testing? And further than that what do people test? Just JavaScript? Links? Forms? Hardcoded content?
任何想法将不胜感激.
推荐答案
几个月前我也有同样的问题，在与许多开发人员交谈并进行了大量研究后，我发现了这一点.您应该对 JavaScript 进行单元测试，编写一小组 UI 集成测试，并避免使用记录和回放测试工具.让我更详细地解释一下.
I had the same questions a few months ago and, after talking to many developers and doing a lot of research, this is what I found out. You should unit test your JavaScript, write a small set of UI integration tests and avoid record and playback testing tools. Let me explain that in more detail.
首先，考虑测试金字塔.这是 Mike Cohn 创建的一个有趣的类比，它将帮助您决定应该进行哪种测试.金字塔的底部是单元测试，它们是可靠的并且可以提供快速的反馈.这些应该是您的测试策略的基础，因此占据了金字塔的最大部分.在顶部，您有 UI 测试.这些是直接与您的 UI 交互的测试，例如 Selenium.尽管这些测试可能会帮助您发现错误，但它们的成本更高，并且反馈速度很慢.此外，根据您使用的工具，它们会变得非常脆弱，最终您将花费更多时间来维护这些测试，而不是编写实际的生产代码.中间的服务层包括不需要 UI 的集成测试.例如，在 Rails 中，您将直接测试 REST 接口，而不是与 DOM 元素交互.
First, consider the test pyramid. This is a interesting analogy created by Mike Cohn that will help you decide which kind of testing you should be doing. At the bottom of the pyramid are the unit tests, which are solid and provide fast feedback. These should be the foundation of your test strategy and thus occupy the largest part of the pyramid. At the top, you have the UI tests. Those are the tests that interact with your UI directly, like Selenium does for example. Although these tests might help you find bugs, they are more expensive and provide very slow feedback. Also, depending on the tool you use, they become very brittle and you will end up spending more time maintaining these tests than writing actual production code. The service layer, in the middle, includes integration tests that do not require an UI. In Rails, for instance, you would test your REST interface directly instead of interacting with the DOM elements.
现在，回到你的问题.我发现我可以大大减少我的项目中的错误数量，这是一个用 Spring Roo (Java) 编写的带有大量 JavaScript 的 Web 应用程序，只需为 JS 编写足够的单元测试.在我的应用程序中，有很多用 JS 编写的逻辑，这就是我在这里测试的那种东西.我不关心页面的实际外观或动画是否按应有的方式播放.我测试我在 JS 中编写的模块是否会执行预期的逻辑，是否正确分配了元素类以及是否很好地处理了错误情况.对于这些测试，我一直在使用 Jasmine.这是一个很棒的工具.它很容易学习并且有很好的模拟能力，被称为间谍.如果您使用 jQuery，Jasmine-jQuery 会添加更多强大的功能.特别是，它允许您指定固定装置，它们是 HTML 代码的片段，因此您不必手动模拟 DOM.我已将此工具与 maven 集成，这些测试是我的 CI 策略的一部分.
Now, back to your question. I found out that I could greatly reduce the number of bugs in my project, which is a web application written in Spring Roo (Java) with tons of JavaScript, simply by writing enough unit tests for JS. In my application, there is a lot of logic written in JS and that is the kind of thing that I am testing here. I am not concerned about how the page will actually look or if the animations plays as they should. I test if the modules I write in JS will execute the expected logic, if element classes are correctly assigned and if error conditions are well handled. For these tests, I've been using Jasmine. This is a great tool. It is very easy to learn and has nice mocking capabilities, which are called spies. Jasmine-jQuery adds more great functionality if you are using jQuery. In particular, it allows you to specify fixtures, which are snippets of the HTML code, so you don't have to manually mock the DOM. I have integrated this tool with maven and these tests are part of my CI strategy.
你必须小心 UI 测试，特别是如果你依赖像 Selenium 这样的记录/播放工具.由于 UI 经常更改，因此这些测试会不断中断，您将花费大量时间来确定测试是否真的失败或者它们是否已经过时.此外，它们没有像单元测试那样增加价值.由于它们需要一个集成的环境来运行，因此您通常喜欢在完成开发后才运行它们，此时修复的成本更高.
You have to be careful with UI tests, specially if you rely on record/playback tools like Selenium. Since the UI changes often, these tests keep breaking and you will spend a lot of time finding out if the tests really failed or if they are just outdated. Also, they don't add as much value as unit tests. Since they need an integrated environment to run, you will mostly like run them only after you finished developing, when the cost of fixing things is higher.
但是，对于冒烟/回归测试，UI 测试非常有用.如果您需要使这些自动化，那么您应该注意一些危险.编写您的测试，不要记录它们.记录的测试通常依赖于自动生成的 xpath，这些 xpath 会因您对代码所做的每一个小改动而中断.我相信 Cucumber 是编写这些测试的一个很好的框架，你可以将它与 WebDriver 一起使用来自动化浏览器交互.考虑测试的代码.在 UI 测试中，您必须使元素更容易找到，这样您就不必依赖复杂的 xpath.在您通常不会经常使用的地方添加 class 和 id 元素.不要为每一个小的极端情况编写测试.这些测试的编写成本很高，运行时间也很长.您应该专注于探索大部分功能的案例.如果您在这个级别编写了太多测试，您可能会测试您之前在单元测试中测试过的相同功能(假设您已经编写了它们).
For smoke/regression tests, however, UI tests are very useful. If you need to automate these, then you should watch out for some dangers. Write your tests, don't record them. Recorded tests usually rely on automatically generated xpaths that break for every little change you do on your code. I believe Cucumber is a good framework for writing these tests and you can use it along with WebDriver to automate the browser interaction. Code thinking about tests. In UI tests, you will have to make elements easier to find so you don't have to rely on complex xpaths. Adding class and id elements where you usually wouldn't will be frequent. Don't write tests for every small corner case. These tests are expensive to write and take too long to run. You should focus on the cases that explore most of your functionality. If you write too many tests at this level you will probably test the same functionality that you have previously tested on your unit tests (supposing you have written them).
在我当前的项目中，我使用 Spock 和 Geb 编写 UI 测试.我发现这些工具很棒.它们是用 Groovy 编写的，更适合我的 Java 项目.
In my current project I am using Spock and Geb to write the UI tests. I find these tools amazing. They are written in Groovy, which suits better my Java project.
这篇关于前端测试:测试什么以及如何测试，使用什么工具?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
