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

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

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

我走对了吗?

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

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

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

不要浪费时间去理头发。

先写测试。

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

结果是这样的:

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

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

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

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

我相信这取决于:

1. 您正在使用的第三方。

   我认为没有必要测试 INSERT 查询在SQL Server中正确插入行,但可以测试某些不受欢迎的Web服务是否在测试过程中收到预期的结果。

2. 建立外部依赖关系有多困难,成本有多高。

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