如果我们直接命中数据库来编写/执行/运行CRUD操作的单元测试用例,这是正确的方法吗?
答案 0 :(得分:0)
测试基础架构或数据访问相关代码通常被认为是集成测试(与单元测试相反),尽管可以使用这两种方法,并且存在许多工具来促进数据访问的单元测试层。就其本质而言,除非您选择模拟数据访问层,否则此类测试几乎总是涉及网络访问的某些元素,因此您最终至少要破坏strict unit testing的一个规则。
就我个人而言,我认为直接点击数据库专门测试数据访问代码是完全可以的,并且尝试将一个非常有效的集成测试场景变成一个单元测试就没有什么意义,只需将它变成一个& #34;单元测试"。也就是说,您应该意识到,由于网络的延迟,这通常会导致时间损失,并且会引入其他变量,例如网络可用性,这些变量可能会使测试更加脆弱。
正如一些评论建议你可以决定模拟你的数据库,这是一个很适合你需要的选项。但是,为什么这可能不合适有很多原因(参见here和here),即(取自第二个链接):
您开始创建一个严重偏离的替代系统 你的生产系统。这基本上意味着:
- 对您的测试系统进行测试的结果(几乎)没有意义
- 您的测试不会涵盖生产系统中一些最复杂的方面
- 你将开始花太多时间调整测试而不是实现有用的业务逻辑
如果您确实选择直接调用数据库而不是模拟它,那么您可能会发现有用的一种方法是备份有问题的数据库(如果资源允许,最好是定期备份)并针对此运行所有集成测试。通过这种方式,您可以针对实时数据的良好副本测试代码,而无需针对实际实时数据运行测试。