为什么在编写单元测试用例时编写模拟对象？

目前，我们正在项目中编写单元测试用例。数据库方法的实现存在并且运行良好。在这种情况下，为什么我们需要编写模拟对象？有什么具体原因吗？为什么我不能直接测试DAO限制？

您不应该模拟对数据库的调用，因为那样会破坏目的。例如，您应该模拟的是从服务层调用DAO。通过模拟，您可以单独测试方法。

假设您有一个具有以下架构的餐厅模拟：

Cook <=> Server <=> Customer

您要独立测试每一层。这Server是您的服务层，Cook可以将其视为DAO。该Server是你想在测试嘲笑什么Customer，而且Cook是要模拟当什么测试Server。该Cook单元测试，但是，应该验证实现返回一个汉堡包当一个汉堡包奉命而不是胶轮。

与数据库一起测试businesslogic是完全可以的。但是即使您使用nunit或junit或phpunit执行这些测试，这些测试也称为集成测试。

单元测试是专门的测试，其中隔离测试（即没有数据库的buisinesslogic）很重要。伪造/伪造/残骸用于强制这种隔离。

简单：测试实际的DAO而不是数据库内容。

假设您的DAO Person类具有方法getByName（）。您编写一个测试，然后调用Person.getByName（“ John Smith”）。假设测试失败，因为有人从数据库中删除了John的记录。现在，每个CI软件和您的主管/检查者都可以声称您的软件有故障，而实际上不是。如果您模拟数据库，则可以从正确的表中获得正确的行，从而证明您的DAO有效。

如果您真的想测试数据库本身，即：如果执行某些DAO方法将数据置于某种状态，那么这也是可能的。更重要的是，对于古怪的数据模型（EAV，嵌套树集），它确实很有帮助，在这些模型中，您不能指望数据库提供防弹完整性。看一下DBUnit，让您的生活更轻松。

另一个原因是避免实际运行数据库命令的执行时间。看起来似乎不多，但是建立和断开连接的开销最终会加起来，并且与使用模拟对象相比，最有可能显着增加运行测试套件的总时间。

为了隔离正在测试的课程。否则，如果测试失败，您如何知道问题出在您正在测试的类中还是其依赖项之一。