数据驱动单元测试

Question

什么是测试依赖于数据库数据的API的最佳实践？在“持续集成”环境中运行单元测试作为构建过程的一部分时，我需要注意哪些问题？我的意思是，您是否应将数据库部署为构建脚本的一部分（可能运行安装程序），还是应该选择硬编码数据[使用带有XML的MSTest数据驱动单元测试]？

我知道可以为业务逻辑层模拟数据层，但是如果DAL中的SQL语句出现问题怎么办？我确实需要访问数据库，对吧？

好的...这是一连串的问题 :)... 您有什么想法？

- Vyas Bharghava

Answer 1

尽可能地模拟代码以避免完全访问数据库，但我认为在某个阶段测试SQL是必要的。如果您编写测试并访问数据库，则避免头痛的一个关键提示是确保设置将数据放入已知状态，而不是依赖于已有合适的数据。

当然，永远不要对您的实时数据库进行测试！但这是不言而喻的 :)

- andygeers

---

那么你是在SetUp方法中简单地删除所有数据，并将手工编写的SQL作为数据库测试用例的第一步执行，对吗？ - Kasper

@Kasper - 这假设你已经设置好了数据库[最好是通过运行构建的SQL脚本]... 当你有太多测试装置时，我认为最好的方法是首先使用种子数据设置数据库。 - Vyas Bharghava

Answer 2

如上所述，除非你想无休止地调整测试和数据，否则请使用mocking来模拟单元测试中的DB调用。测试SQL语句意味着更多的是集成测试。将其与单元测试分开运行，它们是两个不同的实体。

- Andrew Cowenhoven

---

安德鲁，我不确定...你是说DAL不能/不应该进行单元测试，而应该在集成期间进行测试吗？ - Vyas Bharghava

如果您已经自己编写了数据访问层（DAL），那么您应该绝对进行单元测试。我的观点是，使用模拟而不是真实的数据库调用来进行单元测试会更加清晰。虽然在某些情况下可能无法实现模拟，但如果可以模拟，一定要这样做。 - Andrew Cowenhoven

Answer 3

自动清空测试数据库并用测试工具数据填充它是个好主意，这些测试工具应该被假定在所有需要连接到数据库的测试中都已经存在。每次测试前重置数据库以确保隔离性，因为一个失败的测试可能会导致后续测试的错误，如果必须按顺序运行测试以获得一致结果，那么情况就会变得混乱。

你可以使用工具(DBUnit、DBUnit.NET等)来清除并填充数据库，或者编写自己的实用程序类来完成同样的任务。

正如你所说，其他层应该与实际连接数据库的类相互解耦，因此测试涉及数据库的需求仅限于对代码库的小部分进行测试。你的访问数据库的组件可以被模拟/存根化，以适应依赖它们的所有内容。

- LeedsSideStreets

Answer 4

我做的一件事是创建静态方法，返回已知状态的测试数据。然后，我会使用“虚拟”DAL返回这些数据，就好像我实际上在调用数据库一样。至于测试SQL /存储过程，我使用SQL Management Studio进行测试。你的情况可能有所不同！

- Brian Lee

---

如果SQL是动态生成的，例如不同的WHERE子句等，该怎么办？ - andygeers