.NET单元测试用于读取/保存数据到数据库

Question

我读到的关于单元测试的大部分内容都是关于测试你的类及其行为.但是,如何测试将数据保存到数据库并从数据库中读取数据.在我们的项目中,保存和读取数据是通过Flex应用程序使用的服务完成的(使用WebORB作为网关).例如,服务读取所有可以访问某个模块的用户.您如何测试实际返回的用户是否有权访问该模块的用户？

有时能够测试从数据库中加载数据需要数据库中已存在数据.在我们的一些测试中,我们首先需要将大量的testdata保存到数据库中,然后才能测试阅读内容......

同样的事情对存储过程也有效.如果数据库中没有数据,如何测试sp？现实是,为了测试某些存储过程,我们需要十个表中的数据......

thx,Lieven Cardoen

Answer 1

这更像是集成测试,而不是单元测试.

我在这种情况下做的是我构建一个非持久化测试,在test-db中加载测试所需的数据,然后运行单元测试.之后,它处理当前事务,因此不存储任何数据.

这里最大的问题是,如果您的客户出现故障 - 您无法运行此类测试......另一个问题是,每次运行此类测试时,test-db中的数据都将被重置.

Answer 2

您可以对 db 操作进行测试，但如果可能，请尽量避免它，否则：

• 它们会比普通测试运行得慢（它们更有可能是集成测试）
• 它们需要更多的设置/拆卸工作（db/schema/table 数据）
• 它们引入了对您的测试框架的外部依赖

您的类没有将与数据库相关的工作与其他工作（例如业务逻辑）分开，这也可能是一种代码异味。然而它可能不是，我们有一个框架测试来验证自动生成的 SQL 脚本在插入新数据后返回预期的递增标识值，AFAIK 除了对数据库执行它之外，没有办法测试此代码是否有效。您可以模拟它，或者只是假设如果 SQL 与您期望的匹配，那么就可以了，但我不喜欢这个假设，因为很多其他代码都依赖于它。

根据您的测试框架，您应该将这些测试标记为 [Database] 相关，允许您将它们与其他测试分开。

Answer 3

我同意@Gambrinus。通常，对数据层进行单元测试几乎是不可能的。最好的办法是提供一个强大的数据层接口，并在业务层中对该接口进行模拟，然后保存数据质量测试以进行集成测试。

我已经看到过尝试对ORM工具进行模拟的尝试（这使LINQ很有趣），但是它们并没有测试查询的正确性，只是测试以测试人员认为应该编写的方式编写。由于测试人员通常是针对ORM编写查询的人员，因此这毫无价值。