Clean Code Architecture – Testing Considerations

Software Testing folks, while validating and verifying the architecture, need to understand about what architecture model is being used. In today’s blog, let’s look at renowned Robert Martin (a.k.a. Uncle Bob)’s Clean Code Architecture and the testing considerations related to it.

I like the Clean Code architecture, and I especially like the model that’s depicted as “A.k.a (unclebob’s style)” in Mattia Battiston’s github. What do I like so much about it?

1. It clearly demarcates the entry points and data providers. In the original version that’s shown in Clean Code blog, it is not that much clear.
2. The provision of configuration for entry points and data providers is great.
3. It makes devising the testing strategy simple (Note: not the developer’s ‘Testing pyramid’ testing strategy, but test engineer’s testing strategy)

Note that any architecture model is just that, a model. It can/should be customized according your specific scenario and needs.

Now let’s look at the testing considerations of Clean Code architecture model.

You would go with something like this (not necessarily in that order) :

1. Test plans for entry points (API, GUI, CLI, …)
2. Test plans for data providers (Data sources, and also cloud-based and on-premises considerations)
3. Test plans for configuration of entry points and data providers
4. Test plans for use cases a.k.a solution tests
5. Test plans for core business logic
6. Test plans for interfaces between each layers
7. Test plans for design considerations

See? It’s so clear and simple, and that’s why I like this architecture model. As always, there will be yay-sayers and nay-sayers with anything, but let’s not get into that because it is out of scope.

What do you think? You like it? Have you checked what architecture model your developers are doing? Let me know in the comments. Also, would be glad to talk if you would like to contact me regarding this. Happy Testing!