Question

我怀疑在我的C＃应用程序中编写单元测试用例。我有一个有3种方法的课，比如

InsertEmp(int empid, string empname)
UpdateEmp(int empid, string empname)
SelectEmp(int empid)

我怀疑是否需要为所有3种方法编写单元测试用例？因为，当我使用一些测试数据为InsertEmp和UpdateEmp编写单元测试用例时，该测试数据总是插入（或更新）到我的数据库中。

这有效吗？

Answer 1

嗯，你在测试什么？如果您正在与物理数据库进行交互，那么您不是单元测试，而是集成测试。拥有这些方法的类是否与数据库紧密耦合，还是可以使用模拟数据库？

如果它可以使用mock，那么在实例化它时将该mock提供给类并使用该mock（或假，或者存根，有lots of subtle terminology）来验证对这些方法的调用是否导致了预期的交互与数据库。

如果它无法使用模拟并且与数据库紧密耦合，那么您无法单独对该数据库进行单元测试。那时你有两个选择：

将其与数据库实现分离。
决定是否有值得单元测试的逻辑。如果所有这些方法在内部都是委托插入/更新/选择命令到数据库那么他们实际上做任何需要进行单元测试的东西。 100％的代码覆盖率很好，但在这种情况下你实际测试的是什么？

如果此类内部包含实际逻辑，并且不仅仅是直接委托给数据库组件的包装器，那么它应该从该组件解耦以用于测试目的。如果它不包含任何实际逻辑，我仍然鼓励驱动器达到100％的覆盖范围，但是会把它放在优先级列表中。

编辑：要考虑的另一件事是这个特定对象如何适合您的整体业务运营。理想情况下，被测试的大部分逻辑是业务逻辑，与这些数据库命令无关。因此，大部分测试都是模拟此对象来测试业务逻辑，而不是直接测试此对象。

在这种情况下，您可以通过使用它（而不是模拟）来实现业务逻辑操作的集成测试，从而实现此对象的代码覆盖（紧密耦合或其他方式）。也就是说，不是直接调用这个对象的方法，而是调用业务逻辑操作，他们自己调用该对象上的方法，有效地测试它。

无论如何，个人（原子）业务操作应该是事务隔离的，因此您应该能够完成测试并且不能提交工作单元。这将有效地测试这些，作为对数据库的集成测试，而不会留下副作用。