我正在尝试编写一些单元测试来测试我的服务层，我认为我做得很好，服务层作为对存储库的依赖，所以我正在使用 RhinoMocks 模拟存储库，所以我正在测试服务层“没有”命中很棒的数据库。
现在我需要测试我的存储库层，它直接连接到数据库，所以我必须测试它不是吗？除了测试，我别无选择？
如果我测试另一个没有命中数据库的存储库实现，那么这不是测试我的实现。
我已经设法模拟出所有较低层，因此任何依赖于需要一段时间才能运行的代码的东西。存储库，然后我嘲笑了这一点。结果是我对存储库下层的所有测试都快速完成并且不会命中数据库。
问题是我现在如何处理存储库。我必须对其进行测试，但它依赖于 SQL 数据库。
嗯，一般的答案是这样的。我会编写单元测试来验证存储库层的逻辑，并在一个新类中分解 sql 依赖项并在 repo 的测试中模拟它。如果存储库层只包含一个 sql 连接并且没有逻辑，那么我认为没有什么可以进行单元测试的。那么你更适合与数据库连接的集成测试。
因此，模拟您不拥有的代码是一种不好的做法，我认为对您来说最好的选择是通过验收/集成测试来测试存储库
您当然可以在不与数据库对话的情况下测试您的存储库层。大多数 ADO.net 类都是可模拟的，如果您注意如何创建它们并且注意耦合到接口而不是具体化。不幸的是，ADO.net 是在 mocking 成为一种非常流行的做法之前创建的，而且它仍然有点痛苦。
我心中真正的问题是您是否应该尝试嘲笑它们。模拟的好处是双重的：它们运行得更快，并且它们迫使您封装有关数据库的更多细节（如果您想这样做，可以更容易地切换出数据库技术）。功能测试的好处是它们还可以测试您的数据库层（存储过程等），可以说它们更容易编写，并且更容易维护，因为如果进行了数据库更改，集成测试会自动通知，而不是你们寻找模拟出来的测试。
我会说“最好”的方法是使用最小起订量和真实数据库来测试它们，因为这可以让你两全其美。然而，这当然是相当昂贵的。