我的测试有问题。有一些花哨的程序的算法。该算法从 [-999,999; 范围内获取一个随机数；+999,999]，将其视为表中的 id 号，并在数据库中执行一些随机操作。这意味着我需要大量调用该方法以确保随机数分布正确。
我想使用 TDD 编写所有代码（只是为了多学一点）。
问题是我不知道如何在考虑到 TDD 原则的情况下测试算法。
根据 TDD，如果不先编写测试，则不应运行任何代码。
我想到的解决方案之一是在主类中有一个名为 debug(text) 的虚拟方法。此方法在生产代码中不会执行任何操作。但是，然后我将创建一个重载此方法的子类，这一次它将存储一些有趣的信息。稍后可以通过测试使用此信息来确定该功能是否正常工作。数据库连接将被模拟并且什么也不做。
另一种解决方案是创建一个模拟数据库连接，该连接将存储有趣的信息，稍后在测试中使用。但是，创建这样一个连接将是大量的工作，我认为不值得花时间在上面。
稍后将进行集成测试以检查数据库是否正确更改。但是集成测试不是 TDD 的一部分。
我是否遇到了 TDD 失败、无用或太难使用的地方？
是你的随机数函数吗？
它是：随机数生成器应该在使用它的任何东西之外进行测试。
它不是：你根本不应该测试它，除非你真的需要验证它的随机性。IMO 的投资回报率不是很高，但这完全取决于您的实际需求。
DB 功能应该假设 RNG 实际上是 R，并且应该与 RNG分开测试——在测试期间您可能不想使用 RNG。至少，您可能希望播种 RNG 以使测试可重复——这可能会使正确性更难验证。
以下是您的代码库的一些假设：
1) 对存储过程的调用在数据访问代码中。
2) 数据访问代码实现一个接口。
3）您想用TDD编写的业务逻辑可以将数据访问代码注入到它的构造函数中。
如果是这种情况，您可以使用模拟框架来模拟您的数据访问代码。不调用实际的存储过程。
可以使用 TDD 开发新代码。
你应该重新考虑你的设计。单元测试（通过 TDD 或稍后添加测试）应该完全隔离地测试每个类。
在您的情况下，您有一些不同的功能：
通过使用诸如依赖注入和模拟之类的设计模式，可以对这些中的每一个进行完全隔离的测试。
单元测试不应依赖于随机行为。这样，它们将变得脆弱且难以维护。
因此，在您的情况下，您将通过大量运行随机数生成器并检查结果是否在预期范围内来测试随机数生成器。无论一天中的什么时间，该测试每次运行时都应该成功。
对于数据库部分，我将创建一个界面来隐藏您的数据库代码（查看Repository 模式）。在您的单元测试中，您可以模拟此接口并检查是否使用正确的参数调用了正确的函数。在您的集成测试中，您可以使用真正的 Repository 实现。
然后第二个测试检查您的数据库查找是否正常工作。检查传递的“随机数”是否正确用于在您的数据库模拟上调用正确的方法。
第三个测试将检查是否针对您的数据库模拟执行了正确的代码。
几个月前，我为 .NET 杂志写了一篇关于单元测试和一些最佳实践的文章。也许它可以提供帮助：单元测试，地狱还是天堂？