问单元测试数据库驱动的.NET应用程序

EN

答案是嘲笑

然而，我发现这样做的方法如下。

将DAL分成2层。底层只执行对数据库的原子读写操作--这些对象都实现了一组接口IReadFromDB和IWriteToDB。

然后，您可以在更高的DAL级别创建读写业务逻辑，而不是引用将对数据库进行读写的对象，而是引用接口并使用属性来替代功能。我倾向于在构造器中包含所需的函数对象，以便可以说“开箱即用”。

这将使得“交换”功能以及对业务逻辑进行单元测试变得轻而易举。

至于测试数据库读写...我还没有找到一种不涉及工作的方法。我通常对数据库的副本使用不同的连接字符串，然后编写单元测试的数据生成和清理代码，以使数据库的状态在前后保持不变。

是的，这很耗时...然而，它不会有疏远客户的风险。这取决于你的优先级。

还有人提到了性能测试。我不认为这是单元测试的一部分。我通常使用测试工具结合调试代码来做到这一点，原因很简单，因为小部件的性能通常是误导性的-当你移到大图上时，实际上是外壳问题的部件通常不是我经验中本地化测试会标记的部件。

我认为最好的做法是模拟所有对数据库的访问-只需在调用时返回一些预先确定的静态数据-你不需要测试数据库是如何工作的-你需要测试你的单元行为。你的单元测试与外部交互越少--它就越好。

通过mocking，您将能够检查对数据库的调用是否有效，而无需真正调用它，所以我认为这是您需要的。

我建议模拟数据访问级别。在这种情况下使用mock的好处包括: 1)单元测试将运行得更快。如果他们必须做连接到数据库、提取数据等全部工作，那么成本将变得昂贵。昂贵的测试=人们停止运行它们/开始对它们失去信心！2)您可以测试大量的场景，而不必经历设置合适的测试/静态数据的麻烦，在测试开始之前，您必须确保这些数据始终存在于数据库中。3)从等式中去掉外部数据库系统意味着您只测试您想要测试的.NET代码。没有外部依赖。

您可以使用一个执行纯数据库交互的数据访问层，然后对其进行模拟。或者，在.NET代码中使用模拟SqlCommands等。