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

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

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

test: should create article 

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

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

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

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

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

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

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

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

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

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

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

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

  • 我可以在我的框中运行2s以下的隔离系统测试。 对我的编码快乐来说,这是足够快的反馈。
  • 我依靠云测试运行器和大型套件的并行化。

我认为本地和云的速度和并行化今天都很好,并且只会随着时间的推移而变得更好。 因此,如果您今天开始使用新应用程序,我相信系统测试是一个更安全的选择。