Should I separate unit tests and integration tests?

Question

I have to write unit tests and integration tests for a project.

• Should all tests be put into a single tests folder?
• Or should unit tests and integration tests each be in a separate tests folder?
• Or should I even put them into separate projects?

If I keep them together, are there any advantages or drawbacks with this approach?

• Robbie Dee: If you are operating in a CI environment, the important thing is that they can readily be identified (by attribute etc) as integration tests don't always run on the build server.
• mouviciel: Related: Testing: unit vs. integration vs. others, what is the need for separation?

Answer 1

In general: yes, you should put integration tests and unit tests into different folders. Often, programmers don't draw a clear line between these two kinds of tests and just write whatever kind of test is useful. But integration tests tend to be slower, because they often involve:

• Database queries
• Network requests
• Time-dependent behaviour
• Large amounts of data

In contrast, an unit test would mock any expensive operations, so unit tests tend to run quickly (in fact, the slowest part of running the test is often the test framework itself).

When a programmer is working on the system they are in an edit–test cycle. The faster they get test feedback and the shorter the cycle is, the more productive they can be. So there we want to only run important test that complete quickly. The complete test suite would only be executed as part of a QA process, e.g. on a CI server.

This means that large test suites should be categorized. Can we only select unit tests for a particular component? Can we exclude slow tests? One simple way to do this is to maintain different test suites in different directories. If you only have very few tests, a single directory would also be OK as long as a programmer can easily select a subset of tests.

Whatever allows a programmer to get feedback quickly is good. The most comprehensive test suite doesn't matter if it isn't executed regularly.

Further reading:

• Testing: unit vs. integration vs. others, what is the need for separation? which was linked by mouviciel above.
• Should I Separate Unit Tests from Integration Tests? on my blog, which discusses this answer in a bit more detail.

• ihebiheb: When separating the folders, do you keep each of them in the same package as the production code (so you can test protected methods) ? Example, you make a maven module for unit tests and another maven module for the integration tests. Like that, you can separate them and still easily test protected methods.
• amon: @ihebiheb In Java, using package visibility is quite frowned upon. In some cases it can be helpful to use it and to access these APIs from unit tests. But in general, that's unnecessary. Integration-style tests never need access to package-private members. Whether or not to put the tests into a separate Maven project depends on how you want to run and deploy them. I'm not that into Java/Maven to be able to tell you what is sensible here.