Do you separate your unit tests from your integration tests? [closed]

Question

I was just wondering if anyone else just sees integration tests as just a special unit test. I have, however, heard from other programmers that it is a good idea to separate your unit tests and integration test. I was wondering if someone could explain why this is a good idea. What sorts of advantages would there be to treating integration and unit tests as completely different? For example, I have seen separate folders and packages for integration tests and unit tests. I would be of the opinion that a single test package containing both unit tests and integration tests would be sufficient as they both are basically the same concept.

Answer 1

I see them as different for the following reason.

• Unit tests can be performed on a single class/module in the developer's environment.
• Integration tests should be performed in an environment that resembles the actual production setup.

Unit tests are kept deliberately "lightweight" so that the developer can run them as often as needed with minimal cost.

Answer 2

Speed is the primary reason. You want your unit tests to be as fast as possible so that you can run them as often as possible. You should still run your integration tests, but running them once before a check-in should be enough IMO. The unit test suite should be run much more often - ideally with every refactoring.

I work in an environment where we have about 15k junit tests with unit and integration tests completely mixed. The full suite takes about a half hour to run. Developers avoid running it and find mistakes later than they should. Sometimes they check in after running only a subset of the tests and include a bug which breaks the continuous build.

Start separating your tests early. It's very hard to once you have a large suite.