何时选择系统测试而不是集成测试Rails 5.1?

Zia*_*mar 17 testing integration-testing ruby-on-rails acceptance-testing capybara

随着Rails 5.1的发布,它们包括了系统测试.这意味着我们也可以在Rails中测试我们的JavaScript.我看到Rails指南解释了以两种方式创建文章的示例测试:通过系统测试和集成测试.

现在问题是:在Rails 5.1之前,我在集成测试中编写了复杂的测试用例.但现在我有两个选项来编写测试用例.我可以写测试用例

test: should create article
Run Code Online (Sandbox Code Playgroud)

在集成测试中,我也可以在系统测试中编写相同的测试用例.

那么我何时应该选择系统测试来编写测试用例以及何时选择集成测试?

jdn*_*dno 20

MikDiet给出了简短的答案.有关长期答案,请查看有关系统和集成测试的文档.

系统测试允许在真实浏览器或无头驱动程序中运行测试,以测试与应用程序的完整用户交互.

一个快速的经验法则是,所有与Javascript交互的测试都需要作为系统测试运行.但您也可以使用它们来测试响应式布局,因为您可以指定浏览器的屏幕大小.

集成测试用于测试应用程序的各个部分如何交互.它们通常用于测试我们的应用程序中的重要工作流程.

集成测试是不同的,因为它们不是通过浏览器运行的.它们仍然允许您与结果页面的HTML进行交互,但请记住它是您使用的静态输出.

在集成测试中,您主要关注控制器操作的行为,而不是用户看到和交互的内容.这部分文档可能有助于您了解集成测试的全部内容:控制器的功能测试.

  • 我不会这么说.系统测试或多或少Minitest相当于RSpec的功能规格.从高层次来看,它们几乎是一样的.在较低的层次上,系统测试更容易设置,现在可能更快一些,因为它们与Rails紧密集成.但据我所知,RSpec计划将系统测试的API用于其功能规范,这将使它们完全相同,只是语法不同. (2认同)

jma*_*bia 9

TL;DR:我会在我今天开始的任何应用程序中使用系统测试而不是集成测试。集成测试的唯一优势是速度。

我认为系统测试比集成测试有两个很大的优势:

  • 他们测试与真实屏幕的交互,而不是对模拟这些进行合成请求。
  • 它们更加现实和全面。例如,一段破碎的 Javascript 将使规范失败,而在集成测试中它将被忽略。

我认为集成测试的唯一好处是速度。它们确实要快得多(检查我做的这个实验)。对我来说,速度差异并不是一个大问题,因为:

  • 我可以在 2 秒内在我的盒子中运行隔离系统测试。对于我的编码快乐来说,这是足够快的反馈。
  • 我依赖于大型套件并行化的云测试运行器。

我认为本地和云的速度和并行化在今天已经足够好了,而且只会随着时间的推移而变得更好。所以我相信如果你今天开始一个新的应用程序,系统测试是一个更安全的赌注。