测试依赖于数据库数据的API的最佳做法是什么？ 在作为构建过程的一部分运行单元测试的“持续集成”环境中，我需要注意哪些问题？我的意思是你将数据库部署为构建脚本的一部分（可能运行安装程序），还是应该使用硬编码数据[使用XML进行MSTest数据驱动单元测试]？
我知道我可以模拟业务逻辑层的数据层但是如果我在DAL的SQL语句中遇到问题怎么办？我确实需要点击数据库，对吗？
嗯......那是一大堆问题：）......想法？
答案 0 :(得分：5)
尽可能地模拟代码以避免完全访问数据库，但在我看来，你需要在线上的某个地方测试你的SQL。如果您确实编写了打到数据库的测试，那么避免头痛的一个关键提示是确保您的设置将数据转换为已知状态，而不是依赖于那些已经存在合适数据的数据。
当然，永远不要对你的实时数据库进行测试！但不言而喻：）
答案 1 :(得分：5)
如上所述，使用模拟来模拟单元测试中的DB调用，除非您想无休止地调整测试和数据。测试sql语句意味着更多的integration test。与单元测试分开运行，它们是2种不同的野兽。
答案 2 :(得分：3)
最好自动擦除测试数据库，然后使用测试工具数据填充它，这些数据将被假定为需要连接到数据库的所有测试。需要在每次测试之前重置数据库以进行适当的隔离 - 如果您必须按特定顺序运行测试以获得一致的结果，那么输入错误数据的失败测试可能会导致测试失败并导致错误。
您可以使用工具（DBUnit，DBUnit.NET，其他人）清除和填充数据库，或者只是制作自己的实用程序类来执行相同的操作。
正如您所说，其他层应该与实际命中数据库的类充分分离，因此测试中涉及的任何类型数据库的需求仅限于运行代码库的一小部分的测试。您的数据库访问组件可以被模拟/存根以获取依赖于它们的所有内容。
答案 3 :(得分：0)
我做的一件事是创建静态方法，返回已知状态的测试数据。然后我会使用“假的”DAL来返回这些数据，就像我实际上正在调用数据库一样。至于测试sql /存储过程，我使用SQL Management Studio对其进行了测试。 YMMV！