从单元测试到集成测试的有效过渡

Question

我正在研究如何在即将开展的项目中执行测试.为了在开发过程的早期发现错误,开发人员将在实际代码(TDDish)之前编写单元测试.单元测试将单独关注单元(在这种情况下是一种方法),因此依赖性将被模拟等等.

现在,我还想在与其他单位交互时对这些单元进行测试,我认为应该有一个有效的最佳实践,因为已经编写了单元测试.我的想法是单元测试将被重用,但被模拟的对象将被删除并替换为真实的对象.我现在的不同想法是:

我认为所有这些方法的方式都有利有弊.哪个是首选,为什么？有没有更好的方法从单元测试到集成测试的有效过渡？或者这通常以其他方式完成？

Answer 1

我会选择第三种选择

这是因为单元测试和集成测试有不同的目的.单元测试表明,单独的功能单独工作.集成测试表明,当它们彼此交互时,不同的功能仍然有效.

因此,对于单元测试,您希望模拟事物,以便您只测试一个功能.

对于集成测试模拟尽可能少.

我会把它们放在不同的项目中.在我的地方运作良好的是使用NUnit和Moq进行单元测试项目.编写代码时写入TDD.集成测试是Specflow/Selenium,功能文件是在计划会话中借助产品所有者编写的,因此我们可以验证我们是否提供了所有者想要的内容.

这确实可以在短期内创造额外的工作,但可以减少错误,更容易维护和交付匹配要求.

Answer 2

我同意大多数其他答案，即单元测试应该与集成测试分开（选项3）。

但我不同意你的反对论点：

[...] 然而，这（将单元与集成测试分开）将 需要大量冗余代码，并且维护测试用例的工作量将增加一倍。

使用测试数据生成对象可能需要大量工作，但这可以重构为测试辅助类（又名ObjectMother），可以在单元测试和集成测试中使用，因此不需要冗余

在单元测试中，您检查被测类的不同条件。

对于集成测试，没有必要重新检查所有这些特殊情况。相反，您检查组件是否协同工作。

例子

您可能会对 4 种引发异常的不同情况进行单元测试。对于集成，无需重新测试所有 4 个条件。一项与异常相关的集成测试足以验证集成系统是否可以处理异常。