模拟与测试数据库？

Question

早些时候我问过这个问题如何正确地对我的 DAL 进行单元测试？，我没有回答的一件事是，如果真正测试我的 DAL 就是拥有一个测试数据库，那么模拟与测试数据库的作用是什么？

除此之外，另一个人建议“在单元测试结束时使用事务和回滚，因此数据库是干净的”，即测试数据库。 你们觉得这种测试+测试DB+事务回滚（所以db不是真正写的）测试DAL的方法怎么样？

完整地说，我的 DAL 是使用实体框架构建的，数据库中没有存储过程。 由于 EF 太新了，我确实需要测试 DAL 以确保它们正常工作。

Answer 1

我认为您可能需要进行一些集成测试来检查数据库结构强制执行的逻辑，例如约束、触发器、自动增量列等。但是，对于单元测试，您应该模拟 DAL 所使用的任何框架组件根据您的需要（在单元测试中）依赖来仅测试您已编码的那些组件。 您实际上并不需要测试 SqlCommand 或 SqlConnection 上的方法（例如）。 您应该假设您使用的框架组件可以工作，并为它们创建存根或模拟，将已知数据（好的、坏的、异常）返回到您的方法，以确保您的方法正常工作。 如果不进行模拟，您将负责在数据库中生成数据并确保其正确。 您还保留了对网络、数据库本身等的开放依赖关系，这可能会使您的测试变得脆弱。

此外，单元测试并不能消除对其他类型测试的需要。 集成测试和验收测试仍然有效并且需要完成。 它们可能不需要以与单元测试相同的频率完成，也可能不需要像通过单元测试提高代码质量一样广泛，但单元测试并不是灵丹妙药。

Answer 2

在测试数据访问代码时，我没有发现模拟非常有用。 单元测试的目的是验证与数据库相关的代码是否有效，模拟数据库会阻碍测试。

在测试业务代码时，模拟确实变得有用。 您可以模拟数据库调用以返回测试数据并验证业务逻辑在这些情况下的行为。

关于事务的使用 - 这当然是可能的，只要您的体系结构有空间在测试开始时启动事务，然后在该事务内执行单元测试的所有与数据库相关的调用。 但从未尝试过。

Answer 3

将单元测试放入可回滚的事务中听起来很老套。
相反，我有代码在测试运行之前（即在我的测试类的构造函数中）清除数据库中的任何 CRUD（即不是静态/引用数据的任何内容）。 当测试失败时，将数据保留在数据库中有助于检查失败的原因。

Answer 4

我们使用了事务性单元测试，并多次防止了 Hibernate 映射问题。 否则 - 什么是单元测试？ 像 List这样的小事 getAllItems()？ :)

Answer 5

不过，您不仅仅是测试您的应用程序。 您还将测试您的配置以及存储过程和视图。 这些记录在您的单元测试中。

Answer 6

通过使用测试数据库，您就有可能在数据库本身或 DAL 与数据库之间的通信路径（网络等）上引起问题。 模拟消除了这些可能性。

Answer 7

您不仅必须考虑数据库的状态，还必须考虑可用性。 如果您的数据库离线，为什么所有 DAL 测试都会失败？

您需要测试的是您的 DAL 发出正确的命令来创建/检索/更新/删除。 您不需要为此执行 SQL，您只需使用对象持久性框架并检查您是否为其提供了正确的指令。

Answer 8

问题很可能出在原来的问题上。 一些更流行的 MVC 示例通过返回 DbSet 来使用快捷方式，例如：

public class MusicStoreEntities : DbContext
    {
        public DbSet<Album> Albums { get; set; }
        public DbSet<Genre> Genres { get; set; }
        public DbSet<Artist> Artists { get; set; }
        public DbSet<Cart> Carts { get; set; }
        public DbSet<Order> Orders { get; set; }
        public DbSet<OrderDetail> OrderDetails { get; set; }
    }

对我来说，这与持久性的实现紧密结合，我认为这是一件坏事。 最好返回很容易被嘲笑的 List 。