单元测试 – 从测试覆盖范围中排除代码

>我嘲笑我的界面
>我使用IOC,因此可以注入我的模拟ojbects
>我确保我的测试运行,覆盖率增加,我很高兴.

然后…

>我创建实际执行操作的派生类,例如转到数据库或写入消息队列等.

这是代码覆盖率下降的地方 – 我感到很难过.

但随后,我在这些具体课程中大量传播[CoverageExclude],并且覆盖范围再次上升.

但后来感觉不舒服,我觉得很脏.我不知何故觉得我在作弊,尽管不可能对具体课程进行单元测试.

我有兴趣了解您的项目是如何组织的,即您如何物理安排可以针对无法测试的代码进行测试的代码.

我想也许一个很好的解决方案是将不可测试的具体类型分离到它们自己的程序集中,然后禁止在包含可测试代码的程序集中使用[CoverageExclude].当在可测试程序集中错误地找到此属性时,这也可以更容易地创建NDepend规则以使构建失败.

编辑：这个问题的本质涉及这样一个事实：你可以测试使用你的模拟接口的东西,但你不能(或不应该！)UNIT测试那些接口真正实现的对象.这是一个例子：

public void ApplyPatchAndReboot( )
{ 
    _patcher.ApplyPatch( ) ;
    _rebooter.Reboot( ) ;
}

修补程序和重新启动程序注入构造函数：

public SystemUpdater(IApplyPatches patcher,IRebootTheSystem rebooter)...

单元测试看起来像：

public void should_reboot_the_system( )
{
    ... new SystemUpdater(mockedPatcher,mockedRebooter);
    update.ApplyPatchAndReboot( );
}

这很好 – 我的UNIT-TEST覆盖率是100％.我现在写道：

public class ReallyRebootTheSystemForReal : IRebootTheSystem
{
    ... call some API to really (REALLY!) reboot
}

我的UNIT-TEST覆盖率下降了,没有办法UNIT-TEST新课程.当然,我会添加一个功能测试并在我有20分钟的时间运行它(！).

所以,我想我的问题归结为这样一个事实,即接近100％的UNIT-TEST覆盖率是很好的.换句话说,能够对100％的系统行为进行单元测试是件好事.在上面的示例中,修补程序的BEHAVIOR应该重新启动计算机.我们可以肯定地验证. ReallyRebootTheSytemForReal类型不仅仅是行为 – 它有副作用,这意味着它不能进行单元测试.由于它不能进行单元测试,因此会影响测试覆盖百分比.所以,

>这些事情是否会降低单位测试覆盖率？
>他们是否应该被隔离到他们自己的集会中,人们期望0％UNIT-TEST覆盖？
>如果这样的具体类型如此之小(在Cyclomatic Complexity中),单元测试(或其他)是多余的