单元测试用例编写的基本规则

本文关键字：规则 测试用例 单元 | 更新日期: 2023-09-27 18:21:41

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

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

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

这有效吗？

单元测试用例编写的基本规则

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

如果它可以使用mock，那么在实例化它时将该mock提供给类，并使用该mock（或false，或stub，有很多微妙的术语）来验证对这些方法的调用是否导致了与数据库的预期交互。

如果它不能使用mock并且与数据库紧密耦合，那么就不能将它与数据库隔离开来进行单元测试。在这一点上，你有两个选择：

  1. 将其与数据库实现解耦
  2. 决定是否有值得进行单元测试的逻辑。如果所有这些方法在内部都是将insert/update/select命令委托给数据库，那么它们实际上不会执行任何需要进行单元测试的操作。100%的代码覆盖率是不错的，但在这种情况下，您实际测试的是什么

如果这个类内部包含实际的逻辑，而不仅仅是直接委托给数据库组件的包装器，那么出于测试目的，它应该与该组件解耦。如果它不包含任何实际的逻辑，我仍然支持100%的覆盖率，但会把它放在优先级列表的很低的位置。

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

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

无论如何，单个（原子）业务操作都应该是事务隔离的，因此您应该能够运行整个测试，而不提交工作单元。这将有效地测试这些，就像针对数据库的集成测试一样，不会留下副作用。

相关文章：