Do you separate your unit tests from your integrat

问题:

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.

回答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.

回答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.

回答3:

Yep. Typically unit tests are scoped at class level, so they exist in an environment together with mock objects. Integration tests, on the other hand, do all the tricks by keeping references to your real assembly types.

I just don't see how one would organize both unit and integration into a single project.

回答4:

if you limit the notion of 'unit test' to scope at the class level, then yes, keep them separate

however, if you define the smallest relevant testable unit as a feature then some of your 'unit' tests will technically be 'integration' tests

the rehashing of the various definitions/interpretations of the terms is largely irrelevant though, partitioning of your test suites should be a function of the scope of the components being tested and the time required to perform the test.

For example, if all of your tests (unit, integration, regression, or whatever) apply against a single assembly and run in a few seconds, then keep them all together. But if some of your tests require six clean installation machines on a subnet while others do not, it makes sense to separate the first set of tests from the latter

summary: the distinction of 'unit' and 'integration' tests is irrelevant; package test suites based on operational scope