代码之家 › 专栏 › 技术社区 › jyoungdev Thilo

在编写单元测试之前编写集成测试是常见的吗?

integration-testing automated-tests language-agnostic unit-testing

jyoungdev Thilo · 技术社区 · 14 年前

在编写单元测试之前编写集成测试是常见的吗?它是传统的、好主意还是最佳实践?

在我看来,这似乎是一件合乎逻辑的事情,尤其是在第一次使用某些第三方API时:在测试自己的代码与第三方软件的正确交互之前,您需要知道如何使用第三方软件——即,您必须测试自己对如何与第三方API交互的理解(通过集成在测试代码是否正确使用之前(通过模拟第三方API的单元测试),对吗?

我走对了吗?

编辑

谢谢大家的回答。我刚刚发布了一个 similar / related question .

5 回复 | 直到 14 年前

Chris 14 年前

当任务是针对第三方API进行开发时,我做的第一件事是编写原型(如果愿意,可以编写集成测试)以获得预期/期望的结果。然后,我创建一些单元测试来强制实现这种期望,并将原型重构为我将继续使用的实际代码。

是的,我觉得这很典型。从最纯粹的意义上讲,这可能不是TDD,但我同意。

S.Lott 14 年前

我走对了吗?

您是否使用测试来驱动开发?即TDD?

如果是这样,你就走对了。

“集成测试”和“单元测试”是模糊的定义。学者们可以在试图找到区分它们的方法时把头发分开。

不要浪费时间去理头发。

先写测试。

Mark Simpson 14 年前

我不确定这有多普遍,但我肯定已经看到,更高级别的测试是提倡的第一步。例如,在 Growing Object-Oriented Software Guided by Tests 首先,作者建议创建一个功能/验收测试脚手架,然后通过编写高级验收测试开始驱动开发(验收测试位于测试三角的顶端,中间是集成测试,底部是单元测试,所以它实际上是相同的原则)。

结果是这样的:

写入失败的功能测试特征X
写入失败的单元测试
通过单元测试
功能测试通过了吗?如果没有,再写一封单元测试失败并执行下一个街区。

Andrey Shchekin 14 年前

嗯,是的,我通常也是这样,但这真的取决于你和什么一起工作以及你有多相信它。

例如,对于与数据库一起工作的东西,集成测试通常比单元测试更可靠,因为例如,nhibernate可以并且将为某些条件生成不正确的查询。

另一方面,如果您的算法是一个复杂的算法,从第一次尝试(例如复杂的regex/解析,或复杂的业务规则)就很难正确地编写,那么单元测试可能更有意义,因为您不希望等待(通常较慢的)集成测试。

DixonD 14 年前

我相信这取决于:

您正在使用的第三方。

我认为没有必要测试 INSERT 查询在SQL Server中正确插入行,但可以测试某些不受欢迎的Web服务是否在测试过程中收到预期的结果。
建立外部依赖关系有多困难,成本有多高。

我无法想象,如果金额超过1000美元的交易成功,集成测试将使用支付处理器进行测试:)