The goal of agile software engineering (ASE) is to continuously improve applications. This includes enhancing functionality, yes, but also the improvement of existing code and design.
Test automation is so important for ASE because any improvement starts with the ability to keep the existing functionality – that is, to avoid regression. Since high-quality applications have more test code than product code, the maintainability and reusability of this test code is crucial. The solution is to extract some technical and repeatedly used code from the test classes over to a test infrastructure of help classes. However, test automation is also an enabler of refactoring – the iterative and incremental improvement of the structure and implementation of applications.
I’ve put together a series of books and E-Bites through SAP PRESS that helps you to work test automation into your development processes. Let’s take a look at each book and the key points they teach.
The test-oriented improvement process has proved in practice to be the most efficient way to refactor existing code. This process not only leads to an effective test suite, it also builds the test infrastructure of an application, which, in turn, is a prerequisite for test-driven maintenance. My book Test-Driven Development with ABAP Objects explains how to design a test infrastructure, and also shows (with real applications) how to implement it—even for legacy applications. Furthermore, this book points out how to train and coach a team to follow the test-oriented improvement process successfully.
According to the test pyramid pattern, the test suite of an application should consist of three things:
- Very many unit tests covering single classes
- Many component tests verifying the collaboration of the classes in packages
- Enough application tests verifying the collaboration of these components and documenting the main use cases of the application.
For fast execution of this test suite during refactoring, the test pyramid should be fully isolated. An isolated pyramid allows for efficient defect localization and flexible test case design. However, the flexible injection of test doubles requires that all classes are decoupled by interfaces and factories. My E-Bite Designing Testable ABAP Classes and Packages introduces a standard design for encapsulated, decoupled, and testable classes and packages. The test-oriented improvement process requires these design skills whenever a new class is created – for example, when a small class with a single responsibility is extracted from a large class or function group.
Likewise, the test-oriented improvement process repeatedly deals with test data. Since the majority of test code is about creating and using test data—be it to provide input to the code under test, to verify its output, or to configure a test double, the handling of test data determines to a great extent the efficiency of test automation. My E-Bite Test Data Classes for ABAP introduces an object-oriented representation of test data. Test data classes can be reused on all levels of the test pyramid for the non-technical and duplication-free buildup of test data. Further, they integrate well with the OSQL or CDS Test Double Frameworks. Altogether, test data classes enable readable and maintainable tests in an efficient way.
The book and the E-Bites are all self-contained and thus can be read in any order. However, since the two E-Bites are deep-dives of integral parts of the test-oriented improvement process, my recommendation is that you first learn with the book about the entire process and how it supports your agile development approach, and then enhance your skills with the E-Bites.
No question, this is just part of the broader learning journey of an SAP development expert. If you are a beginner, then other SAP PRESS books and E-Bites will make it easier for you to get started. But if you’re comfortable around ABAP, I encourage you to dive into these advanced topics and make your testing as smooth as can be.