在编写单元测试之前编写集成测试是否常见？它是传统的，好主意还是最佳实践？
在我看来，这似乎是合乎逻辑的事情，尤其是在第一次使用某些第三方API时：您需要知道如何使用第三方软件才能测试自己的代码与第三方软件的适当交互 - 即，您必须测试您对如何与第三方API进行交互（通过集成测试）的理解，然后才能测试您的代码以便正确使用（通过模拟掉第三方的单元测试 - 派对API），对吗？
我是在正确的道路上吗？
修改的
谢谢大家的回答。我刚刚发布了similar / related question。
答案 0 :(得分：7)
当负责开发第三方API时，我要做的第一件事是编写原型（集成测试，如果你愿意的话）以获得预期/期望的结果。然后我创建了一些单元测试来强制执行该期望，并将原型重构为我将继续使用的实际代码。
所以是的，IMO，这很典型。从最纯粹的意义上说它可能不是TDD，但我对此很好。
答案 1 :(得分：4)
我是在正确的道路上吗？
您是否正在使用测试来推动开发？即，TDD？
如果是这样，那么你走的是正确的道路。
“集成测试”和“单元测试”是不明确的定义。学者们可以试图找到区分它们的方法。
不要把时间浪费在头发分裂上。
首先编写测试。
答案 2 :(得分：3)
我不确定它有多常见，但我确实认为更高级别的测试是第一步。例如，在Growing Object-Oriented Software Guided by Tests中，作者建议的第一件事是创建功能/验收测试脚手架，然后通过编写高级验收测试开始推动开发（验收测试位于测试三角形的顶端，带有集成测试在中间和底部的单元测试，所以它是相同的原则，真的）。
它最终会像：
答案 3 :(得分：1)
嗯，是的，我经常以同样的方式行事，但这取决于你的工作内容以及你对它的信任程度。
例如，对于使用数据库的东西，集成测试通常比单元测试更可靠，因为，例如，NHibernate可以并且将针对某些标准生成不正确的查询。
另一方面，如果您的算法是一个复杂的算法，从第一次尝试（复杂的正则表达式/解析，或复杂的业务规则）很难正确编写，那么单元测试可能更有意义，因为你不想等待（往往更慢）整合的。
答案 4 :(得分：0)
我认为这取决于：
您正在使用的第三方。
我认为测试INSERT查询是否在SQL Server中正确插入行是没有意义的，但您可以测试一些不受欢迎的Web服务是否在测试中收到预期结果
设置外部依赖有多困难，需要多少钱。
如果金额超过1000美元的交易成功，我无法想象使用支付处理器进行测试的集成测试：）