52

我一直在为我的 Ruby 代码编写测试，但作为一个前端开发人员，我显然有兴趣将它带入我为我的前端代码编写的代码中。我一直在玩很多不同的选择：

人们使用什么进行测试？除此之外，人们还测试什么？只是 JavaScript？链接？形式？硬编码的内容？

任何想法将不胜感激。

4

3 回答 3

83

几个月前我也有同样的问题，在与许多开发人员交谈并进行了大量研究之后，我发现了这一点。您应该对 JavaScript 进行单元测试，编写一小组 UI 集成测试，并避免使用记录和回放测试工具。让我更详细地解释一下。

首先，考虑测试金字塔. 这是 Mike Cohn 创建的一个有趣的类比，它将帮助您决定应该进行哪种测试。金字塔的底部是单元测试，它们是可靠的并且可以提供快速的反馈。这些应该是您的测试策略的基础，因此占据了金字塔的最大部分。在顶部，您有 UI 测试。这些是直接与您的 UI 交互的测试，例如 Selenium。尽管这些测试可能会帮助您发现错误，但它们的成本更高，并且反馈速度很慢。此外，根据您使用的工具，它们会变得非常脆弱，最终您将花费更多时间来维护这些测试，而不是编写实际的生产代码。中间的服务层包括不需要 UI 的集成测试。例如，在 Rails 中，

现在，回到你的问题。我发现我可以大大减少我的项目中的错误数量，这是一个用 Spring Roo (Java) 编写的带有大量 JavaScript 的 Web 应用程序，只需为 JS 编写足够的单元测试。在我的应用程序中，有很多用 JS 编写的逻辑，这就是我在这里测试的那种东西。我不关心页面的实际外观或动画是否按应有的方式播放。我测试我在 JS 中编写的模块是否会执行预期的逻辑，是否正确分配了元素类以及是否很好地处理了错误情况。对于这些测试，我一直在使用 Jasmine。这是一个很棒的工具。它很容易学习并且有很好的模拟能力，被称为间谍。Jasmine-jQuery如果您使用 jQuery，它会添加更多强大的功能。特别是，它允许您指定固定装置，它们是 HTML 代码的片段，因此您不必手动模拟 DOM。我已将此工具与 maven 集成，这些测试是我的 CI 策略的一部分。

你必须小心 UI 测试，特别是如果你依赖像 Selenium 这样的记录/播放工具。由于 UI 经常更改，因此这些测试会不断中断，您将花费大量时间来确定测试是否真的失败或者它们是否已经过时。此外，它们没有像单元测试那样增加价值。由于它们需要一个集成的环境来运行，因此您通常喜欢在完成开发后才运行它们，此时修复的成本更高。

然而，对于冒烟/回归测试，UI 测试非常有用。如果您需要使这些自动化，那么您应该注意一些危险。写你的测试，不要记录它们。记录的测试通常依赖于自动生成的 xpath，这些 xpath 会因您对代码所做的每一个小改动而中断。我相信 Cucumber 是编写这些测试的一个很好的框架，你可以将它与 WebDriver 一起使用来自动化浏览器交互。代码思考测试。在 UI 测试中，您必须使元素更容易找到，这样您就不必依赖复杂的 xpath。在您通常不会经常使用的地方添加 class 和 id 元素。不要为每个小的极端情况编写测试。这些测试的编写成本很高，运行时间也很长。您应该专注于探索大部分功能的案例。如果您在这个级别编写了太多测试，您可能会测试您之前在单元测试中测试过的相同功能（假设您已经编写了它们）。

在我当前的项目中，我使用 Spock 和 Geb 编写 UI 测试。我发现这些工具很棒。它们是用 Groovy 编写的，更适合我的 Java 项目。

于 2012-11-13T12:55:26.300 回答
4

有很多选择和工具。但他们的选择取决于您是拥有 Web UI 还是桌面应用程序？

假设您提到的工具是 Web UI。我建议 Selenium（又名 WebDriver）：http ://seleniumhq.org/docs/

它支持多种语言（Ruby 在列表中）。它可以在各种浏览器上运行，它非常易于使用，并提供大量教程和提示。哦，当然，它是免费的 :)

于 2012-07-31T15:36:57.957 回答
2

我虽然这篇文章得到了很多喜欢，但我会发布我对我的问题的回答，因为我现在确实编写了很多测试，并且你测试前端的方式现在已经发生了很大变化。

因此，在有限元测试方面，我花了很多时间将karma与Jasmine一起使用，尽管 karma 可以很好地与 mocha 和 qunit 等其他测试套件配合使用。虽然这些都很棒，并且 karma 允许您直接与浏览器交互来运行测试。缺点是随着您的测试套件变大，它可能会变得非常慢。

所以最近我搬到了Jest，它的速度要快得多，如果你的写作反应应用程序，使用带有快照测试的酶会给你很好的覆盖率。谈到覆盖范围 Jest 内置并设置了伊斯坦布尔覆盖范围，并且模拟非常易于使用。缺点是它没有在浏览器中进行测试，并且它使用了一种叫做jsdom的东西，速度很快，但确实有一些麻烦。就我个人而言，我觉得这没什么大不了的，特别是当我通过 webpack/babel 编译我的代码时，这意味着跨浏览器的错误相当少而且相差甚远，所以如果你手动测试通常不是问题（而且 imo 你应该）。

就在 rails 堆栈中的工作而言，现在 webpacker gem 可用并且使用 npm 和 node 通常更例外，这很容易。我建议使用nvm来管理您的节点版本

虽然这不是严格测试，但我也建议使用 linting，因为这也会在您的代码中发现很多问题。对于 JS 我使用更漂亮的eslint和 scss/css 我使用stylelint

至于要测试什么，我认为 Carlos 谈到测试金字塔仍然是相关的，毕竟理论没有改变，只是工具而已。我还要补充一点关于测试的实用性，我总是会测试，但是到什么水平和覆盖范围将取决于项目。管理您的时间并花费数小时/数天测试一个生命周期较短的项目非常重要。更大/更长期的项目，更大的测试套件的好处显然更大。

无论如何，我希望这可以帮助那些看这个问题的人。

于 2017-12-12T10:51:11.417 回答