Is it common to write integration tests before writing unit tests?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

Am I on the right path?

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.

Answer 4

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:

• Write failing functional test for feature X
• Write failing unit test
• Make unit test pass
• Does functional test pass? If not, write another failing unit test and implement the next block.

Answer 5

I believe that it depends on:

1. What 3rd party you are using.

   I think it is no point to test if INSERT query properly inserts rows in SQL Server but you can test if some not popular web-service receives expected result as part of your test

2. How 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 :)