Here is the thing ... you could say that the user of a component, via its API, is a different user. In this case a developer or team. So, component tests are UATs. Sure, but this language looses the focus that UATs have given us of creating automated test as close to the real thing (mouse clicking a button) as possible. Thing is that this makes UATs inherently slow and difficult to test all the corner cases. For example, what if the USB memory stick fails after the user clicks the 'Do It' button but before the save is completed? Hard from a UI level. But if the UI code is moved to its own component and the 'do it' logic in another domain component then this testing is on the domain component via its API. Not hard.
So component tests differ is difficulty, speed, and only the UATs actually test the final functionality. Whenever developers use tests at code level the question is 'how can I know this is the functionality used in the product?'. By componentalizing the products code this risk is greatly mitigated giving the end customer confidence. He/she can believe that the component tests do test the functionality used in the product as the component is clearly identified. A user database component is more likely to provide the functionality of adding a user than the product help framework component.
Critically a component must provide encapsulation, typical via an API. The API is the line of demarcation defining it from integration or unit tests.
The potential advantages are:
- Simpler to test corner cases, more unit test like. An enabler for better tests.
- Test run faster. Essential for Continuous Integration (CI) and a cost saving for any project.
- Componentalization means fast developer and build box compile times.