测试依赖于数据库数据的 API 的最佳实践是什么？在将单元测试作为构建过程的一部分运行的“持续集成”环境中，我需要注意哪些问题？我的意思是您会将您的数据库部署为构建脚本的一部分（可能会运行您的安装程序）还是应该使用硬编码数据[使用带有 XML 的 MSTest 数据驱动单元测试]？
我知道我可以模拟业务逻辑层的数据层，但是如果我在 DAL 中的 SQL 语句有问题怎么办？我确实需要访问数据库，对吗？
嗯......这是一个问题的洪流:)......想法？
Vyas Bharghava
问问题
3193 次
4 回答
5
如前所述，使用模拟来模拟单元测试中的数据库调用，除非你想无休止地摆弄你的测试和数据。测试 sql 语句意味着更多的集成测试。将其与单元测试分开运行，它们是两种不同的野兽。
于 2008-10-28T19:55:45.793 回答
5
您应该尽可能地模拟代码以避免完全访问数据库，但在我看来，您需要在某处测试您的 SQL 是正确的。如果您确实编写了针对数据库的测试，避免头痛的一个关键技巧是确保您的设置将数据置于已知状态，而不是依赖于已经有合适的可用数据。
当然，永远不要针对您的实时数据库进行测试！但这不言而喻:)
于 2008-10-28T17:32:16.800 回答
3
自动擦除测试数据库，然后使用测试工具数据填充它是一个好主意，这些测试工具数据将被假定用于需要连接到数据库的所有测试。每次测试之前都需要重置数据库以进行适当的隔离 - 放入错误数据的失败测试可能会导致随后的测试出现错误的失败，并且如果您必须按特定顺序运行测试以获得一致的结果，它会变得混乱。
您可以使用工具（ DBUnit、DBUnit.NET等）清除和填充数据库，或者只是创建自己的实用程序类来做同样的事情。
正如您所说，其他层应该与实际命中数据库的类充分分离，因此对涉及测试的任何类型的数据库的需求仅限于测试运行代码库的一小部分。您的数据库访问组件可以为依赖它们的所有内容进行模拟/存根。
于 2008-10-28T18:23:27.023 回答
0
我做的一件事是创建返回已知状态的测试数据的静态方法。然后我会使用“假”DAL 来返回这些数据，就好像我实际上是在调用数据库一样。至于测试 sql/存储过程，我使用 SQL Management Studio 进行了测试。YMMV！
于 2008-10-28T17:47:41.183 回答