Skip to content

Unit test, addressing component tests (part 2)

Posted on:September 25, 2023 at 03:41 PM

From part 1, I have placed the problem of term component test test type: it looks like that the team try addressing source file integration as a unit of test. However, as I mentioned before, line coverage and branch coverage metrics surely cover such concern. So I go further to have a personal flavor for its definition.

To address this, I set up my standing point and direction as following:

Then I simply answer this question to identify component for the application:

What else does it require running, so as the application can fulfill all of its functionalities?

Again, here is the application mock from previous post:

Sample application

Here component list from sample application:

In another word, I just slim down the application by not concerning source files but addressing what is mandatory for the application except the application itself.

simplified_app.png

The whole source tree from this approach is now a single component of the application. By this lens, I don’t concern any set of source files, but I see the whole source tree is just only one component of the application. As a result of this, I would say that I should cover following scopes:

As you may notice, each of interaction pair above may produce two set of tests:

Conclusion

So that’s it. This is my definition if I must have for unit test targeting component test. I think I have placed the term well enough as a guidance. Now any software engineer want to have “type” for their unit test, I think by reading what is the scope of current source file, they definitely know how to write tests to cover “king and queen” metrics: line coverage and branch coverage.