Product code without tests is not good, and unclean tests are not good either. They may satisfy test coverage KPIs, but they are hard to use and maintain.
In a nutshell, clean tests are fast, well readable, and avoid duplication. They focus on the test case rather than on technical details and are written using help methods with intent-revealing names and only a few parameters. If those help methods are not only part of the test classes, but also of local or even global help classes, then they are called “test infrastructure.” For every application, such a test infrastructure should be developed with the test-oriented development process, and my SAP PRESS book Test-Driven Development with ABAP Objects demonstrates this for both a legacy and new application in detail.
The test-oriented improvement process, in the figure above, starts with the refactoring of a first test (T1) for a given product code. The refactoring of test code does not only extract test code from test methods to help methods for reuse, but it also gives these help methods signatures that allow them to express the test case with objects rather than with structures and tables. That is, in a business-oriented and thus readable way.
With the resulting test infrastructure, the test coverage can then be extended fast with further tests, here T2 through T4. Each additional test may require an extension of the test infrastructure, but this effort will decrease over time. With an effective test suite in place, the code and design of the product can be refactored safely. As an example, the figure above shows the extraction of a small class with a single responsibility from the product code in question.
If an interface and a factory are used to decouple the extracted class, then existing tests T1 through T4 can be transformed into isolated tests using a test double in lieu of the extracted class. Only at this point is the development complete and the product code ready for release.
The readiness of a product code for release is directly related to the team's ability to perform test-driven maintenance afterwards, as the figure below shows.
This practice solves customer and internal tickets by reproducing the issues with tests. The existence of a test infrastructure is crucial for test-driven maintenance because it enables the team to write further high-quality tests quickly. Further, test isolation gives the team the flexibility to reproduce the customer issue precisely. Later, this new test (C1) and all already delivered tests (T1 to T4) confirm that the reported issue has been solved and no other issue was introduced. The team should follow this process for every new issue reported. During the correction of the next issue (C2), the C1 test ensures that no regression on this already performed correction occurs.
Comments