有没有人在单元测试SQL存储过程方面成功的？
我们为C＃/ C ++代码编写过单元测试，但是在存储过程中拥有数千行业务逻辑，当我们的产品推广到大量用户时，它们才真正得到了真正的测试。
更糟糕的是，这些存储过程中的一些最终会很长，因为在SP之间传递临时表时性能会受到影响。这阻止了我们重构以使代码更简单。
我们已经尝试围绕一些关键存储过程构建单元测试（主要是测试性能），但是发现为这些测试设置测试数据真的很难。例如，我们最终复制测试数据库。除此之外，测试最终对变化非常敏感，甚至是对存储过程的最小变化。或表需要对测试进行大量更改。因此，在由于这些数据库测试间歇性地失败而导致许多构建中断之后，我们只需将它们从构建过程中拉出来。
所以，我的问题的主要部分是：有没有人成功为他们的存储过程编写单元测试？
我的问题的第二部分是使用linq进行单元测试是否更容易？
我想的是，您可以简单地创建一组测试对象，并在“linq to objects”情况下测试您的linq代码，而不是必须设置测试数据表。（我对linq很陌生，所以不知道这是否会起作用）
回答 2
Stack Overflow用户
发布于 2019-04-25 08:01:35
测试存储过程的关键是编写一个脚本，该脚本使用预先计划好的数据填充空白数据库，以便在调用存储过程时产生一致的行为。
我必须投票支持存储过程，并将业务逻辑放在我（和大多数DBA）认为属于数据库的地方。
我知道我们作为软件工程师需要用我们最喜欢的语言编写的精美重构代码来包含我们所有重要的逻辑，但是大批量系统中的性能现实以及数据完整性的关键性质要求我们做出一些妥协。 。Sql代码可能很丑，重复且难以测试，但我无法想象在没有完全控制查询设计的情况下调整数据库的难度。
我经常被迫完全重新设计查询，包括对数据模型的更改，以便在可接受的时间内运行。使用存储过程，我可以确保更改对调用者是透明的，因为存储过程提供了如此出色的封装。
Stack Overflow用户
发布于 2019-04-25 09:09:33
如果你考虑单元测试倾向于促进的代码类型：小的高度内聚和低耦合的例程，那么你几乎应该能够看到问题的至少一部分。
在我愤世嫉俗的世界中，存储过程是RDBMS世界长期以来试图说服您将业务处理转移到数据库的一部分，当您考虑服务器许可证成本往往与处理器数量相关时，这是有意义的。您在数据库中运行的内容越多，它们就越多。
但我得到的印象是，你实际上更关心的是性能，这根本不是单元测试的保留。单元测试应该是相当原子的，旨在检查行为而不是性能。在这种情况下，您几乎肯定需要生产类加载才能检查查询计划。
我认为你需要一个不同类的测试环境。我建议将生产副本作为最简单的，假设安全性不是问题。然后，对于每个候选版本，您从先前版本开始，使用您的发布过程进行迁移（这将为那些良好的测试提供副作用）并运行您的计时。
https://stackoverflow.com/questions/-100001135
复制相似问题