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.
Asked
Active
Viewed 2,320 times
4 Answers
8
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.
joel.neely
- 30,725
- 9
- 56
- 64
-
So, Should I have different classes for Unit Testing and Integration testing? Suppose I have a student class, for testing i should be having StudentUT, StudentIT? #### Because in unit testing I should be mocking dao but in Integration testing its an end to end testing without mocking anything. – Abdul Aug 21 '22 at 04:32
-
Approaches may vary, but I'd ask what kind of object (e.g. Student) has behaviors that are its "own" (isolated, suitable for unit tests) and also has behaviors that require interaction with other objects/components (collaborative, suitable for integration tests). For example, if a Student participates in grading computations to determine status (in good standing, on academic probation, etc.) I'd ask whether the workflow for those collaborations should be managed in a different class and put the integration tests on that class. – joel.neely Aug 22 '22 at 11:22
8
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.
Craig P. Motlin
- 26,452
- 17
- 99
- 126
-
-
So, if single unit test is supposed to be non-dependent on other external dependencies, this means that you can always run unit test separately from other unit/integration tests (we don't have dependency on other external classes/tests). When what is the sense of running full suite of tests if you need to test only 1 class? And other way around, if you integrated your unit into the system, you will need to run full suite of tests anyway to make sure that there are no integration defects. Ofc it will easily take 30 minutes or more, bcz you need to test complete system. – metamaker Aug 27 '17 at 20:05
-
" Developers avoid running it and find mistakes later than they should." - In other words, if your developers run unit tests and find defects in module A after changes in module B, it means that design of your unit tests is broken. – metamaker Aug 27 '17 at 20:09
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.
Dmitri Nesteruk
- 23,067
- 22
- 97
- 166
3
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
Steven A. Lowe
- 60,273
- 18
- 132
- 202