我们正在开发一个Rails应用程序，它有很多页面包含数据报告。典型的报告页面基于相对较大的SQL查询，通常涉及5-8个表连接。
我们偶然发现的基石问题是 - 编写集成测试报告页面。我们的常见集成测试如下：
在测试设置中通过factory_girl在数据库中创建一堆记录，
启动用户登录的capybara方案，进入包含报告的页面，并在其中查看正确的数据。
随着应用程序的增长，我们开始创建更多此类报告页面，我们开始遇到以下问题 - 每个单独测试的设置最终过于庞大，复杂且通常难以阅读和维护。
创建此类测试显着提高了开发人员提供与报告相关的功能的门槛，因为它非常耗时且未针对快乐进行优化。但是，我们仍需要确保我们的报告正确无误。
因此，我的问题是：
应该或不应该使用报告测试网页？
如果我们要测试报告，那么最难以做到的方法是什么？
我们在哪里做错了？
答案 0 :(得分：3)
<强> 1。我们应该或不应该测试报告页面吗？
您一定要测试报告页面。
<强> 2。如果我们应该测试报告，那么最难以做到的方法是什么？
鉴于报告的大小，您可能会遇到以下问题：
当报告发生变化时，您的测试将不再更新。
有了这个，你可能会停止维护你的规格。
首先，您应该区分：
测试该UI显示正确的结果（接受）vs
测试报告是否正确生成（单位和综合）。
使用Capybara的第一个场景UI的测试应该测试UI而不是自己报告。它涵盖了报告数据显示的结果，因为它们是由各自的类生成的，这使我们得出结论，您不需要测试数百万个报告行，而是表格中有正确的列和标题，分页正在工作等。您测试第一，第二和可能的最后一个报告行是否正确显示。
另一方面，第二种方案（报告生成）的测试应测试是否生成报告。这与UI无关，因为您可以将这些报告作为JSON，HTML，Cap＆n Proto和任何可视化方式提供。作为想象练习，图片测试通过JSON响应报告，然后通过HTML再次报告，然后通过其他方法再次报告。很明显，报告生成在全世界都在重复。
这意味着报告生成是核心，应该自行测试。这意味着你应该主要通过单元测试来覆盖它。如果你需要，可以使用它们。巨大的阵列。
通过这种设置，您可以快速进行单元测试，覆盖报告及其边缘情况，进行一些集成测试，确保报告生成部分正确连接，并进行一些覆盖UI（Capybara）的验收测试。 / p>
还记得测试金字塔吗？
第3。我们在哪里做错了？
我没有关于您的设置的所有细节，但似乎主要的误解是认为报告本身就是页面。请记住，您可以生成CSV或XML格式的报告，但它们内部仍然是相同的报告。在软件中，报告可能最终成为具有值的数组。
所以，下次，考虑分离概念。您有生成报告，并且您拥有UI。单独测试它们，然后在两者之间添加一些测试，以确保它们都能很好地集成。
将来，假设您转向单页JS App™和iOS应用程序，您不必摆脱报告生成测试，但UI测试将进入客户端。这证明了UI与报告生成的不同。
答案 1 :(得分：0)
我会发布我们迄今为止的想法。
不要进行集成测试
而是编写集成测试，编写一个较低级别的功能测试，将数据库交互视为与第三方API的交互。
这是怎么回事：
执行一个期望空数据集的SQL查询，尽管验证了：
这种方法的优点是：
factory_girl时代，预加载数据夹具
不是为每个报告测试设置复杂的记录树，而是在整个测试套件之前预先填充DB记录的整个“字段”。
这是怎么回事：
这种方法的优点是：
factory_girl时代要快得多。这种方法的缺点是：