The lack of tests in a system
There are a lot of systems that are never tested. The fact that this does not bother us perhaps speaks to how little credit tests are given in projects. Systems are designed without tests all the time, but sometimes the need arises — maybe a bug was found, or the system needs a rewrite. There are numerous reasons why tests suddenly become important, but important they will become. The fact that the tests are written after the action will make them weak in the beginning, but with time and patience, they will take over the entire development lifecycle.
Providing a baseline
These kinds of systems do not usually have clear requirements represented in the code. Domain rules are scattered and incomplete – silent witnesses from past discussions about types of inputs. If there is no document present or no other resource to contact to know the requirements of the system, there is little left but to test-drive the baseline yourself.
The first tests to touch this baseline are tests on a grander scale: system and integration tests would be the way to go. The problem with system tests is that they are hard to set up and even harder to stabilize. As a first step, this could be the wrong move when getting your team involved. A compromise could be to write integration tests that first test out the basic, and then more advanced interactions with components and external resources. These will already give you a good overview of what the system does and does not provide. Due to the lack of requirements, it will often be the case that a certain test will stumble against wrong implementations. An idea is to provide several skipped integration tests with a descriptive skipped message that explains what the test correctly expects, and how the system incorrectly reacts. This already gives guidance as to what is missing in the system.
Test-drive towards testable system
Once the system has several of these ‘skipped integration tests’ and the interaction between components is established, we have a general idea as to what is considered ‘valid’ and what not. The next would be to add unit tests (both example-based and property-based) that test-drive the hidden domain at these interaction points. It is important that these tests drive the implementation in such a way that a strict domain model is flushed out. This will hold the missing requirements that were previously scattered throughout the system.
Conclusion
This test-drive cycle should continue until the integration tests succeed. The result will be that the system now has clear domain rules which are tested on the lowest level and are validated on a higher level. It is critical to understand that in no step was there a change made that was not tested. Keeping the system requirements in sight without looking at the gigantic gap of where the test should be is a way of keeping every team member involved. System requirements are something that is/should be common knowledge in the team and with this approach, you can focus on those requirements. The tests are the vehicle to get there.
Thanks for reading!
Stijn
Subscribe to our RSS feed