使用TSQLUNIT进行SQL单元测试：您是否需要复制SQL代码？

Question

我正在考虑为我的Tsql存储过程编写一些单元测试，我有两个问题：

1. 我将不得不编写大量SQL来创建测试夹具（在_setup程序中准备的测试数据）

2. 我必须在测试程序中“重写”我的查询，以获得与我正在测试的存储过程的结果进行比较的结果。

考虑到我的数据库有数百个表和非常复杂的存储过程......我不知道这会如何节省我的时间？有什么想法吗？我错过了什么吗？还有其他方法吗？

Answer 1

随着管理人员推动快速发布而不是增加项目范围和预算以强调稳定性，自动化单元测试通常会被搁置。事实是，单元测试需要时间。根据我的经验，其好处远远超过任何缺点。在外部系统调用存储过程的情况下，单元测试对于消除无法预料的问题并在集成测试之前保证稳定性非常宝贵。

关于您的疑虑：

1. 如果您将存储过程进行单元测试所需的任何数据放在XML文件中（可在运行单元测试之前读取），则可以使用标准API例程读取数据以进行读取XML数据并可能重复使用数据进行多次测试。在事务上下文中运行每个测试，该事务在测试结束时回滚，以允许在测试运行开始时配置一次整体环境，而不必为每个单独的测试执行大量步骤。单元测试可以与自动夜间构建过程捆绑在一起，以进一步防范代码。

   最初会有一些开销，但随着您和您的团队越来越熟悉单元测试概念以及如何利用可重用性，这会随着时间的推移而减少。

2. 您不需要重新编写查询来比较结果。标准方案可能如下所示：

   1. 加载测试数据并准备环境
   2. 开始交易
   3. 使用测试数据运行存储过程
   4. 使用Assert语句
   将实际输出与预期输出进行比较
   5. 如果实际和预期输出不匹配，则测试失败
   6. 如果实际和预期的输出匹配，则测试通过
   7. 回滚交易
      / ......
      对于任何其他测试重复步骤2到7 ... /
      
   8. 清理测试环境

   请记住，您正在测试一组特定条件，以查找通过/失败，因此可以在测试例程中对预期值进行硬编码。

   希望这有帮助，

   比尔

Answer 2

理论上，单元测试（一般来说）意味着更多时间在前面编写测试，但是应该让以后更容易。例如，当您能够非常轻松地发现回归错误时，投入的时间会带来红利。 unit testing上的维基百科条目很好地概述了一般的好处。

在实践中是否对你有好处是一个难以回答的问题 - 取决于项目。

至于“必须重新编写查询以测试查询结果”，显然这不会证明什么。我想您需要做的是设置测试数据，该数据将在运行查询（或其他）时返回可预测的结果，然后测试该特定结果。这样你就可以根据你的心理模型测试查询，而不是根据自身的副本测试查询。

但是，听起来像这样会花费很多时间 - 我可以想象准备SQL存储过程测试将涉及比平均.Net对象测试做更多的设置。

Answer 3

我想知道的是，你为什么要考虑编写单元测试？您是否有数据库的操作问题？难以实施变更吗？管理层是否依赖于单元测试？

如果没有明确的理由，我不会从单位测试开始“为了好玩”。如果有一个运行良好的变更系统，单元测试会增加开销但没有价值。

单元测试也存在严重风险：

1. 人们开始将单元测试视为“质量保证”。只要保持黑客攻击直到单元测试发出绿光，然后它就足以进行生产。
2. 曾经是“快速解决方案”的小变化将会变得更大，因为它们需要（更改）单元测试。通过这种方式，单元测试可以让您更少灵活。
3. 单元测试通常会检查许多与使用生产系统的人无关的事情。因此，单元测试会迫使您将资源泄漏到只有单元测试关心的东西上。

对不起咆哮（我对单元测试的经验不好。）