集成测试、单元测试和代码覆盖率

Question

我正在为一位同事检查一些代码，并在单元测试类中遇到了一个测试，该测试如下所示：

// setup
Foo f = ...
FooToBarConverter ftb = ...
Bar b = ftb.Convert(f); // It is easier to create a Bar by converting it from a Foo than making one 'from scratch'

// test
systemUnderTest.DoSomething(bar);

// assert
Assert.IsTrue(...)

显然，这是一个集成测试，因为它正在测试FooToBarConverter以及被测试的系统，因为它是覆盖DoSomething()方法的唯一测试。我建议将这个测试移到集成测试解决方案中，但是这降低了单元测试的代码覆盖率。我们的目标是100%的单元测试代码覆盖率(是的-我知道100%覆盖率是达到目的的一种手段，而不是目的本身，而100%覆盖的代码不一定是100%正确的代码)。

如果我们将集成测试移出，是否有理由创建单元测试以使覆盖率恢复？

或者，我们的目标是错误的东西，100%的单元测试覆盖率？我们应该以100%的覆盖率为目标，把我们所有的测试(甚至是100%的测试)结合起来？

谢谢。

编辑/更新：

这不是关于如何正确地测试被测试系统的问题(我知道这不是单元测试的原因，我知道如何正确地将它转换为单元测试)，也不是关于FooToBarConverter上的覆盖率的问题。我想要关于被测试系统的代码覆盖率的意见:测试系统上的集成测试是否足够？或者也应该有单元测试？

Answer 1

我认为这里的答案是“视情况而定”。

• 如果您对FooToBarConverter类具有完整的单元测试覆盖率，那么您可能对systemUnderTest的集成测试没有意见，因为您可以自信地说，真正的FooToBarConverter在这个上下文中的行为与预期一样，因此不会错误地影响测试的结果。
• 另一方面，目前还不清楚这个测试的具体目的是什么--当给出一个有效的systemUnderTest时，您是在检查FooToBarConverter的行为，还是systemUnderTest中的其他一些预期的副作用( FooToBarConverter是一个纯粹的巧合)？(也就是说，你确定这不是bar的间接测试吗？)

现在就我个人而言，我建议您也为systemUnderTest进行适当的“纯”单元测试(使用模拟或存根)，因为

• 这将使回归更易于管理；假设将来对FooToBarConverter的某些更改会使其单元测试失败--因此，它们也很可能导致集成测试失败。对于那些查看失败测试而不知道集成测试失败可以被忽略并且只需要修复FooToBarConverter测试的人来说，这可能会让人感到困惑。这是一件小事，我知道，但它可能会节省5分钟重要的一天:)
• 您如何测试阴性情况(当给出一个失效/无效/空的systemUnderTest时，FooToBarConverter的行为)？由于您可能必须为这类案例编写带有存根/模拟的单元测试，所以您也可以在同一个项目/测试类中为好的用例进行单元测试，这要清楚得多--否则您必须在单元测试和集成测试项目中聚合代码覆盖率，以验证systemUnderTest是否完全覆盖了.

另外，不要担心100%的代码覆盖率；拥有它很好，但在实践中很少看到它。我的意思也不是说这是对好的设计实践的一种安慰；简单的现实是，没有一个设计是100%完美的，因此我们可以预料，有时候您只是没有时间/资源/意愿来重构类以允许注入每个依赖项，或者能够为每个缝间交互使用接口等等。

希望这能有所帮助。