问如何测试SQL查询/报表？

EN

1.我们是否应该测试报告页？

你绝对应该测试你的报告页面。

2.如果我们要测试报告，那么最不痛苦的方法是什么？

考虑到报告的大小，您可能会遇到以下问题：

• 你的测试会变得非常慢；
• 您的测试将变得很难阅读和维护，因为庞大的设置；
• 当报告发生变化时，您的测试将停止更新。 有了这个，您可能会停止正确维护您的规范。 因此，首先，您应该区分：
• 测试UI显示正确的结果(接受) vs
• 测试报告是否正确生成(单元和集成)。 第一个场景的测试是UI，它使用Capybara，应该测试UI，而不是报告自己。它涵盖了报表数据显示它们是由它们各自的类生成的，这使我们得出结论，您不需要测试数百万条报告行，而是表具有正确的列和标题，分页工作等等。您将测试第一、第二或者最后一个报表行是否显示正确。 另一方面，第二个场景的测试，即报表生成，应该测试生成报告。这与UI无关，因为您可以以JSON、HTML、Cap和任何可视化方式提供这些报告。作为一种想象练习，图片测试报告通过JSON响应，然后再通过HTML，然后再通过其他方法。很明显，所有的报告生成都是重复的。 这意味着报告生成是核心，应该单独进行测试。这意味着你应该主要通过单元测试来覆盖它。如果你需要的话。巨大的阵列。 使用此设置，您将拥有覆盖报表及其边缘案例的快速单元测试、确保报告生成块正确连接的几个集成测试以及覆盖UI (Capybara)的几个验收测试。 还记得测试金字塔吗？

3.我们做错了什么？

我不知道你的设置的所有细节，但似乎主要的误解是认为报告本身就是页面。请记住，您可以以CSV或XML的形式生成报告，它们在内部仍然是相同的报告。在软件中，报表可能最终成为一个具有值的数组。

所以，下一次，考虑一下分离概念。您有报告生成和UI。分别测试它们，然后在两者之间添加一些测试，以确保它们都集成得很好。

在未来，假设您移动到一个单一的Page应用程序™和™应用程序，您将不需要摆脱您的报告生成测试，但UI测试将进入客户端。这证明UI与报表生成不同。

我会发表我们到目前为止的想法。

完全不做集成测试()

相反，编写集成测试，编写低级功能测试，将DB交互视为与第三方API的交互。

情况是这样的：

1. 存根将查询发送到数据库的对象，模拟我们所期望的DB结果，
2. 依赖任何需要数据的测试结果模拟，
3. 执行期望为空数据集的SQL查询，但验证如下：

- the SQL raised no syntax error,
- the result object returned correct columns,
- the column types are as what we are expecting them to be.

​

这种方法的优点是：

1. 测试设置不再是认知障碍，
2. 这些测试比factory_girl时代的测试要快得多，
3. 如果DB结果(列名集或列类型)发生了一些变化，我们仍然可以通过执行“真实”DB请求来捕捉它。

预加载数据夹具

没有为每个报表测试设置复杂的记录树，而是在整个测试套件之前预先填充一个完整的DB记录“字段”。

情况是这样的：

1. 在套件(或其中包含报表测试的部分)之前，用测试数据日志填充DB。
2. 测试每个报告，而不需要任何进一步的设置。

这种方法的优点是：

1. 测试设置不再是认知障碍--数据总是在你身边，
2. 这些测试比factory_girl时代的测试要快得多。

这种方法的缺点是：

1. 偶尔，当新的报告出现时，我们将不得不将更多的数据添加到"fixtures“设置中，这很可能会破坏现有的测试。修复现有的测试可能会导致新特性的奇怪/不可读的拉请求更改集。