如果我们直接打数据库编写/执行/运行单元测试用例进行CRUD操作，是不是正确的做法？
【问题讨论】：
标签： c# unit-testing asp.net-web-api
测试基础架构或数据访问相关代码通常被认为是集成测试（与单元测试相反），尽管这两种方法都可以使用，并且存在许多工具来促进数据访问的单元测试层。就其本质而言，除非您选择模拟您的数据访问层，否则此类测试几乎总是会涉及网络访问的某些元素，因此您最终至少会违反strict unit testing 的规则之一。
我个人认为直接打数据库来测试数据访问代码是完全可以的，而且试图将一个非常有效的集成测试场景变成一个单元测试场景只是为了让它变成一个“单元测试”。也就是说，您应该明白，由于网络延迟，这通常会导致时间损失，并且会引入其他变量，例如网络可用性，这可能会使测试更加脆弱。
正如一些 cmets 所建议的，您可以决定模拟您的数据库，这可能很适合您的需求。然而，这可能是不可取的原因有很多（参见here 和here），即（取自第二个链接）：
您开始创建一个严重偏离的替代系统 您的生产系统。这实质上意味着：
- 针对您的测试系统的测试结果（几乎）没有意义
- 您的测试不会涵盖生产系统中一些最复杂的方面
- 您将开始花费太多时间来调整测试而不是实现有用的业务逻辑
如果您确实选择直接调用您的数据库而不是模拟它，您可能会发现一种有用的方法是备份有问题的数据库（如果资源允许，最好定期备份）并针对此运行所有集成测试.这样，您就可以针对实时数据的良好副本测试您的代码，而无需针对您的实际实时数据运行测试。
【讨论】：
测试 CRUD 通常被认为是集成测试。就个人而言，我始终建议为您可能会看到 逻辑 失败的任何内容编写自动化测试。集成测试对于端到端测试来说是一件非常好的事情，通常不是标准的 CRUD。我通常不测试标准 CRUD，就像其他人所说的那样，我通常只是模拟我的数据并专注于单元测试我的逻辑。但是，您可以使用单元测试框架进行集成测试以完成标准 CRUD 测试。
根据您使用的数据库类型，一个很好的方法是使用生产数据库的架构创建一个本地数据库，并在测试项目中使用数据播种它。这将使您腾出时间来利用您的类（希望它们是存储库）来练习该测试数据库的所有 CRUD。您需要一个管理该测试数据库（创建、播种、删除）的类，您可以分别在测试的初始化和清理中使用它。有几种方法可以给猫剥皮，请查看Anatomy of a Unit Test 和Assembly Initialize Attribute
关于如何完成集成的演练，我假设您感兴趣的内容。转至Here。
【讨论】：