This great articles explains the difference between unit testing, component level testing and UI testing. At all my previous companies great deal of attention was given to unit testing and less to automated UI testing (end-to-end integration tests). I’ve never seen component testing practiced in these companies.
It’s interesting because as I see it in large applications it’s the component testing that helps most during architecture refactoring or ensures against defects by novice developers. Yet, there’s almost no information on the web on this subject, almost no books on amazon, while there’s a ton of information both on unit testing and automated UI test. Why is it so?
The terms “unit testing” and “component testing” are not defined universally, and different people hold different notions what these terms mean precisely. However, they are generally understood to be the same thing. The ISTQB (a testing qualification organization) does not seem to differentiate between these terms, preferring “component tests” in their literature.
The ISTQB sees the following major testing levels:
- Acceptance tests, which are performed by the customer.
- System tests, which verify requirements on the complete system
- Integration tests, which cover the interaction of components.
- Component tests, which test components in isolation. Unit tests are component tests.
The article you quoted draws a line at the level of granularity: according to the author, the test subject of unit tests would be single methods, whereas component tests would cover whole modules. Also, the focus would move from verification of the component’s contract to validation in the context of the application/whole system. These differences found by that article are not universally recognized. How large the “unit” of an unit test is depends. Often, the unit is a whole class.
Other sources see the difference in the role which performs the tests: whereas unit tests would be performed by developers, component tests and integration tests would be performed by dedicated testers. Again, this difference is not universally recognized. In practice, integration tests always require the assistance of developers, so that test drivers and test stubs can be created to stand in for missing components.
Although I agree that part of the problem is that people seem to disagree on what to call different ‘levels’ of testing and so this complicates matters a bit. The other point I think should be made is that giving advice on unit testing (by which I mean individual functions) or UI testing is much easier to do.
There are some people who dislike ‘mid’ level tests (Integrated Tests Are A Scam).