在编写单元测试之前编写集成测试是否很常见？
在编写单元测试之前编写集成测试是否很常见？它是传统的、好主意还是最佳实践？
在我看来，这似乎是一件合乎逻辑的事情，尤其是在第一次使用某些第 3 方 API 时：您需要知道如何使用第 3 方软件，然后才能测试自己的代码以与第三方软件正确交互。第 3 方软件——即，您必须测试您对如何与第 3 方 API 交互的理解（通过集成测试），然后才能测试您的代码是否正确使用（通过模拟第 3 方 API 的单元测试） ， 正确的？
我走在正确的道路上吗？
编辑
谢谢大家的回答。我刚刚发布了 类似/相关问题。
Is it common to write integration tests before writing unit tests? Is it conventional, a good idea, or best practice?
It just seems like a logical thing to do in my mind, especially when working with some 3rd-party API for the first time: You need to know how to use the 3rd-party software before you can test your own code for proper interaction with 3rd-party software--i.e., you have to test your understanding of how to interact with 3rd-party API's (via integration tests) before you can test your code for proper use (via unit tests that mock away the 3rd-party API), correct?
Am I on the right path?
EDIT
Thank you all for your answers. I just posted a similar / related question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当负责针对第三方 API 进行开发时，我做的第一件事是编写原型（集成测试，如果你愿意的话）以获得预期/期望的结果。然后，我创建一些单元测试来强制执行该期望，并将原型重构为我将在以后使用的实际代码。
所以，是的，在我看来，这很典型。它可能不是最纯粹意义上的 TDD，但我对此很满意。
When tasked with developing against a third party API, the first thing I do is code a prototype (integration test, if you will) to obtain the expected / desired result. I then create some unit tests that enforce that expectation and refactor the prototype into the actual code I will use moving forward.
So yes, IMO, it's pretty typical. It may not be TDD in the purest sense, but I'm OK with that.
您是否使用测试来推动开发？即，TDD？
如果是这样，那么您就走在正确的道路上。
“集成测试”和“单元测试”是模糊的定义。学者们在试图找到区分它们的方法时可谓煞费苦心。
不要把时间浪费在分叉头发上。
首先编写测试。
Are you using Tests to Drive Development? i.e., TDD?
If so, you're on the right path.
"Integration Test" and "Unit Test" are murky definitions. Scholars can split hairs in trying to find ways to distinguish them.
Don't waste time on hair splitting.
Write tests first.
我不确定它有多常见，但我确实看到提倡将更高级别的测试作为第一步。例如，在 Growing Object-Oriented Software Guided by Tests 中，首先作者建议创建一个功能/验收测试脚手架，然后通过编写高级验收测试开始驱动开发（验收测试位于测试三角形的尖端，集成测试位于中间，单元测试位于底部，所以这是相同的原则，真的）。
它最终会变成这样：
功能 X
单元测试失败并实施
下一个街区。
I'm not sure how common it is, but I've certainly seen higher level testing be advocated as a first step. For example, in Growing Object-Oriented Software Guided by Tests, the first thing the author recommends is creating a functional/acceptance test scaffolding, then begin driving development by writing high level acceptance tests (acceptance tests are at the tip of the testing triangle, with integration tests in the middle and unit tests at the bottom, so it's the same principle, really).
It ends up going something like:
feature X
failing unit test and implement the
next block.
嗯，是的，我经常走同样的路，但这实际上取决于你正在做什么以及你对它的信任程度。
例如，对于与数据库一起使用的东西，集成测试通常比单元测试更可靠，因为，例如，NHibernate 可以并且将会针对某些条件生成不正确的查询。
另一方面，如果您的算法是一个复杂的算法，很难从第一次尝试就正确编写（例如复杂的正则表达式/解析，或复杂的业务规则），那么单元测试可能更有意义，因为您不希望等待（通常较慢）集成。
Well, yes, I often go the same way, but it really depends on what you are working with and how much you believe in it.
For example, for stuff that works with database, integration tests are often much more reliable than unit ones, since, for example, NHibernate can and will generate incorrect query for certain criteria.
On the other hand, if your algorithm is a complex one that is hard to write correctly from the first attempt (complex regexes/parsing, for example, or complex business rule), than unit tests may make more sense, since you do not want to wait for (often slower) integration ones.
我相信这取决于：
您使用的第三方。
我认为测试
INSERT查询是否在 SQL Server 中正确插入行是没有意义的，但您可以测试某些不受欢迎的 Web 服务是否收到预期结果作为测试的一部分设置有多困难外部依赖及其成本。
我无法想象使用支付处理器来测试金额超过 1000 美元的交易是否成功的集成测试:)
I believe that it depends on:
What 3rd party you are using.
I think it is no point to test if
INSERTquery properly inserts rows in SQL Server but you can test if some not popular web-service receives expected result as part of your testHow difficult to setup external dependency and how much it costs.
I cannot imagine integration test which uses payment processor for testing if transaction with amount over $1000 succeeds :)