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

答案是嘲笑

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

将DAL分为两层。底部只是对数据库执行原子读写操作——这些对象都实现了一组接口IReadFromDB和IWriteToDB。

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

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

我通常使用不同的连接字符串来复制数据库,然后为单元测试编写数据生成和清理代码,使数据库的状态与之前和之后相同。

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

还有人提到性能测试。我不认为这是单元测试的一部分。我通常将测试工具与调试代码结合使用,这仅仅是因为小部件的性能往往会产生误导-当您进入大画面时,实际上是外壳问题的部件通常不是我的经验中本地化测试将标记的部件。

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

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

1) 单元测试将运行得更快。如果他们必须完成连接数据库、提取数据等全部工作,那么成本将变得昂贵。昂贵的测试=人们停止运行它们/开始对它们失去信心! 2) 您可以测试大量的场景,而不必经历设置适当的测试/静态数据的麻烦,您必须确保这些数据在测试开始之前始终在数据库中。

您可以有一个执行纯db交互的数据访问层,然后模拟它。或者,在.NET代码中使用模拟SqlCommands等。

• 为.NET中实现的数据操作逻辑编写单元测试。要么模拟数据库,要么将数据处理逻辑与数据访问内容完全分离,只需为数据操作例程提供预烘焙的输入数据。
• 创建一个测试整个数据流的集成测试。这个测试也应该是自动化的。将源和目标数据库(从DB脚本或从DB备份)设置为已知状态,运行数据操作逻辑,然后检查结果。
• 如果处理大量数据,您可能还需要创建性能和压力测试。您可以像在集成测试中那样设置数据库,生成一组测试数据,运行组件并检查运行时间,或者检查它是否完成(例如,没有一致性问题、死锁等)

我有两种方法来测试具有数据库依赖性的单元代码:

• TypeMock
• 在TestInitialize()和TestCleanup()子系统中运行的自定义SQL脚本。

使用TypeMock,我可以在代码中伪造数据库数据,这有助于我运行测试,而无需担心清理数据库或恢复备份等。我使用Mock在数据库逻辑之外测试代码,但仍然需要来自数据库的伪造数据。

您应该尝试将代码分层,以便模拟函数的操作。

确实需要与数据库对话的层可以使用一个系统来设置数据并在事务中使用它,您可以在测试结束时回滚该事务。

Test Cancer 这将通过对网络/文件系统/数据库进行昂贵的调用来实现,因为人们会停止运行它们。

您应该有一些调用数据库的测试,但它们应该尽可能地受到限制。

Typemock 用于我们的单元测试。我们不需要为测试更改代码这一事实是一个很大的优点。嘲笑木豆是一条路要走。