mysql - 如何测试 SQL 查询/报告？

Question

我们正在开发一个 Rails 应用程序，它有相当多的数据报告页面。典型的报告页面基于相对较大的 SQL 查询，通常涉及 5-8 个表连接。

我们偶然发现的基石问题是 – 编写集成测试报告页面。我们常见的集成测试如下所示:

1. 通过 factory_girl 在数据库中创建一堆记录在测试设置中，

2. 启动 capybara场景，用户登录，前进到包含报告的页面，并在其中看到正确的数据。

随着应用程序的增长和我们创建更多此类报告页面，我们开始遇到以下问题 - 每个单独测试的设置最终变得太大、太复杂并且通常难以阅读和维护。

创建这样的测试显着提高了开发人员交付与报告相关的功能的阈值，因为它非常耗时并且没有针对快乐进行优化。但是，我们仍然需要确保我们的报告是正确的。

因此，我的问题是:

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

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

3. 我们哪里做错了？

Answer 1

<强>1。我们应该或不应该测试报告页面？

您一定要测试您的报告页面。

<强>2。如果我们应该测试报告，那么最不痛苦的方法是什么？

鉴于报告的大小，您可能会遇到以下问题:

• 你的测试会变得 super 慢；
• 由于庞大的设置，您的测试将变得非常难以阅读和维护；

• 当报告发生变化时，您的测试将停止更新。

  有了这个，您可能会停止正确维护您的规范。

  因此，首先，您应该区分:

• 测试 UI 显示正确的结果(接受)与

• 测试报告是否正确生成(单元和集成)。

  第一个场景(使用 Capybara 的 UI)的测试应该测试 UI 而不是报告本身。它涵盖了报告数据显示它们是由各自的类生成的，这使我们得出结论，您不需要测试数百万个报告行，而是表格具有正确的列和标题，分页是工作等。您将测试第一个、第二个和最后一个报告行是否正确显示。

  另一方面，第二个场景(报告生成)的测试应该测试报告是否已生成。这与 UI 无关，因为您可以将这些报告作为 JSON、HTML、Cap'n Proto 和任何可视化方式提供。作为一个想象力练习，图片测试报告通过 JSON 响应，然后通过 HTML 重新生成，然后通过其他方法重新生成。很明显，报告生成在整个过程中重复进行。

  这意味着报告生成是核心，应该单独进行测试。这意味着您应该主要通过单元测试来覆盖它。如果需要，可以使用大量的。巨大的阵列。

  通过此设置，您将拥有涵盖报告及其边界情况的超快单元测试、确保报告生成部分正确连接的一些集成测试以及涵盖 UI (Capybara) 的一些验收测试。

  还记得测试金字塔吗？

<强>3。我们哪里做错了？

我没有关于您的设置的所有详细信息，但主要的误解似乎是认为报告就是页面本身。请记住，您可以生成 CSV 或 XML 格式的报告，它们在内部仍然是相同的报告。在软件中，报告最终可能会成为一个包含值的数组。

所以，下一次，考虑分离概念。你有报告生成，你有用户界面。分别测试它们，然后在它们之间添加一些测试以确保它们都很好地集成。

在未来，假设您迁移到 Single Page JS App™ 和 iOS 应用程序，您不必摆脱报告生成测试，但 UI 测试会进入客户端。这证明了 UI 不同于报告生成。