Why Are ABAP Test Data Classes Important For Shared Code Ownership?

Fluctuation, retirement, and job rotation make it necessary for technical and business knowledge to be handed over to other ABAP developers.

This not only costs time and energy on the part of the remaining developers who take over these topics, but also bears the risk that detailed knowledge is gradually lost. Additionally, new developers often find it difficult to understand an evolved code base and to comfortably and safely take on initial tasks. In many cases, these beginner developers need the (scarce) time of experienced developers to learn, which further reduces the productivity of the team. Since file-based documentation often cannot keep up with maintenance and further development, it is more efficient and sustainable to keep and share the knowledge about business cases and their implementation with design diagrams and automated tests. Readable tests allow not only a continuous verification of code but also an executable documentation of an application.

But what makes a test readable? Test cases often depend extensively on test data. For instance, a class being tested may import test data, select it from the database, or receive it from a test double. In all these cases, the test data needs to be built beforehand. In the case of ABAP, this test data buildup usually means to select it from a test data container or to create it ad-hoc using the VALUE operator. However, neither of these alternatives is readable, because they both operate on the field level and thus overload the test reader with questionable names and technical details.

What happens if further test methods are needed? This means many developers will copy the complex test data statements and just edit what is different in the new test case. While this duplication allows you to write tests quickly once, it prevents you from reading and maintaining them quickly over time as the test needs updating. This is particularly critical when shared code ownership is wanted and handovers frequently occur.

You can address these challenges with test data classes – that is, the object-oriented representation of test data. This test data can be hierarchies of customizing, transactional, or master data, as the figure below shows. This figure further indicates how test methods of the test suite create test data objects to configure test double objects and call the method under test.

Test data classes offer the following benefits:

• Their methods introduce application-specific names and hide technical details, like the assignment of a mandatory (but not insightful) identifier.
• If defined globally, then test data classes make the test methods readable and the build-up of test data reusable.
• They allow a team for which product code is dominated by function modules to gain practical experience with object-oriented programming in a safe environment.

My SAP PRESS E-Bite Test Data Classes for ABAP introduces this language-independent and standardized concept with many code samples for common test scenarios. Check it out and have your team prepared for any changeover to come.