Testing problems are test results: „If automated checks are difficult to develop and maintain, does that say something about the skill of the tester, the quality of the automation interfaces, or the scope of checks? Or about something else?“ (Michael Bolton, 2011).
If you run into problems to automate a test, this indicates that there is a flaw in the design of the system under test. Certainly, it could be also a problem of your test design…
So, what is needed to support good testability? Mainly observability and controllability.
Source: Alexander Tarlinder (2017)
Observability describes how well the test can determine what the system under test is doing.
„Along with observability, control is probably the key area for testability, particularly so if wanting to implement any automation.“ (Adam Knight 2012).
Controllability describes if the test can set the system under test in a predefined state.
Important design principles, related to separation of concerns, are supporting the testability, i.e.:
- Interface Segregation design principle
- Open Closed design principle
- Robustness principle (Postel’s Law)
With those design principles in mind, let’s look at microservices:
Microservices should be designed and shaped so that they fulfill following key aspects:
- They are responsible for only one functionality.
- They are loosely coupled, communicate with each other via APIs, and shall not share data.
- If there are dependencies needed, consider embedding them.
By implementing design principles which are focusing on decoupling and supporting testability, microservices can be completely decoupled which makes it possible to build, test, and release them independently, i.e. in autonomous Continuous Integration & Continuous Delivery (CI & CD) pipelines.
Note that overusing testability related design changes may lead to a test-induced design damage flow: „Such damage is defined as changes to your code that either facilitates a) easier test-first, b) speedy tests, or c) unit tests, but does so by harming the clarity of the code through — usually through needless indirection and conceptual overhead.“ (David Heinemeier Hansson 2014).
However, if design principles such as Interface Segregation, the Open Closed, and the Robustness principles are followed, the software should support testability while avoiding introduction of design damages.
- Bolton, Michael (September 7, 2011): Blog: Testing Problems Are Test Results. http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/
- Heinemeier Hansson, David (April 29, 2014): Test-induced design damage. http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
- Knight, Adam (July 29, 2012): Putting your Testability Socks On. http://www.a-sisyphean-task.com/2012/07/putting-your-testability-socks-on.html
- Tarlinder, Alexander (2017): Developer Testing. Building Quality into Software. The Addision Wesley Signature Series.