有效的单元测试覆盖率(以及实际应该测试的内容？)

Question

我看到有几个问题基于这个主题,但我有一些具体的例子,我正在努力.我希望有人可以在这里帮助我,因为我是新手测试驱动开发和单元测试.

(我不确定它是否重要,但我使用的是C#与.NET framework 4.0并使用Microsoft的内置测试框架)

首先,是否值得测试非常简单的代码块？例如,对于我的一个类,我有一个Fill方法,它接受10个参数,并根据这些参数设置类中10个属性的值.填充代码实际上只是一系列值设置语句.我已经读过一个好的单元测试应该只断言一件事,但在我看来,为了检查所有这些值是否已正确设置,我必须断言10件事.所以要么我根本不能测试它,相信代码很简单,或者写10个不同的单元测试来检查每个属性.这些都是正确的吗？

第二个例子.我有一个代码块,可以调用一个类的私有方法,最后调用一个Web服务来向用户发送一封电子邮件.我知道我应该为电子邮件服务注入一个模拟Web服务,这样我就不会测试多个类,但是我应该如何测试所有这些私有方法和那个电子邮件调用？

第三个例子与上一个例子类似.我的班级结构看起来像:

控制器---取决于---> IWidget(某些业务对象)&& IDataProvider DataProvider(Implements IDataProvider)---取决于---> WebService WebService ---直接调用--->数据库

现在我有控制器的单元测试(注入模拟Widgets和DataProviders).这一切都很好.我也有Widget的单元测试没有问题.

问题归结于DataProvider和WebService.此特定实例中的WebService除了通过数据提供者的请求并传回数据(由于物理体系结构限制)之外什么都不做.

我无法对DataProvider进行单元测试,因为我不确定如何注入模拟Web服务.我也不确定单元测试DataProvider是否值得,因为我最终只需要编写很多模拟数据集来测试值.同样,我不确定如何对Web服务进行单元测试,因为在这种情况下,WebService的主要功能取决于数据库.再一次,这值得测试吗？如果WebService做了更多,除了仅作为传递但仍依赖于数据库,该怎么办？

我非常感谢任何人在这方面可以提出的任何建议.非常感谢.

Answer 1

我读过，一个好的单元测试应该只断言一件事，但在我看来，为了检查所有这些值是否都已正确设置，我必须断言 10 件事。因此，要么我根本无法测试它，相信代码足够简单，要么编写 10 个不同的单元测试来检查每个属性。

我想说，一个好的单元测试应该测试一个故事或用例 场景，这确实可能涉及多个断言。

如果该方法涉及 10 个作业，确实有可能有些作业被搞乱了，名称拼写错误等，因此单元测试为其（小）价格提供了价值。

我有一段代码，它多次调用类的私有方法，最后调用 Web 服务向用户发送电子邮件。我知道我应该为电子邮件服务注入一个模拟 Web 服务，这样我就不会测试多个类，但是我应该如何测试所有这些私有方法和电子邮件调用是否已进行？

这称为“感知”，即感知您拨打的电话的结果/副作用。答案取决于这些私有方法的实际用途。如果他们组装一些数据最终进入邮件消息，则可以通过消息内容进行测试。如果它们以可以从外部检测到的方式改变对象的内部状态，您就可以验证它。如果这些都不是真的，那么甚至可能会出现这样的情况：这些私有方法最好转移到单独的类的公共接口中，在那里它们可以被正确地进行单元测试。

我在对 DataProvider 进行单元测试时遇到困难，因为我不确定如何注入模拟 Web 服务。我还不确定对 DataProvider 进行单元测试是否值得，因为我最终不得不在大量模拟数据集中编写代码来测试值。

我不一定想要对这些类进行单元测试，这些类实际上是外部组件的包装器。如果那里只有绝对最小量的逻辑，即所有（或最可能的）值得测试的代码被移至其他可单元测试的类，IMO 可以将这些类的测试留给集成/功能测试，测试连接到真实数据库、Web 服务等的整个（子）系统。