043: Modern, solid and testable ABAP Code (Part 4)

In previous episodes, we've looked at why ABAP is still an important programming language, what pattern exist, how we can use them effectively, and how to build unit tests that are based on these pattern and thus provide added value. In this episode, we'll look at some tips that you can use in your daily work if you want to work with ABAP unit tests and your own development flow.

Tools

What important tool information can you find online that can help you improve your code, simplify your programming style, or even remove old code? You should especially check out the "Clean ABAP" style guide. This is a GitHub repository, populated by the community, that combines the most common programming pattern and best practices into a single document. There you'll find dos and don'ts to help you in your daily development. It explains which statements you should use, how they are structured, and what the best practices are for building object-oriented, maintainable code. The document is relatively long. It's helpful to get a general overview first, perhaps read the entire document once, and then refer back to it whenever you have questions or are unsure about something.

Next, we recommend the ABAP Cleaner, a plugin for the ABAP Development Tools or Eclipse. With this plugin, you automatically receive a large number of rules that can format your source code directly after development. This allows you to quickly create simpler, standard-compliant code without having to invest significant effort in actual formatting. Essentially, the ABAP Cleaner works similarly to the Pretty Printer of the past, except that it performs even more formatting and automatically cleans up outdated statements or overly complex instructions. This saves you a great deal of time and energy when it comes to cleaning up source code. With a single keystroke, your source code is as clean as your colleagues'. Variants and settings can be shared within teams. This way, you're not the only one using it; everyone on the team uses the same variant, resulting in a consistent code appearance. This helps enormously with later maintenance, because code is read far more often than it is written. Consistently formatted code that is easily readable for everyone is ultimately very easy to maintain.

Have you looked at the document and installed the ABAP Cleaner? Then there's also codePal, an open-source project for the ABAP Test Cockpit. With it, you can run additional checks in the system that verify whether your code also complies with the Clean ABAP Style Guide. This is incredibly useful if your team has committed to a common standard. This way, everything is checked again during the release process to ensure it meets the guidelines. Perhaps a colleague forgot the ABAP Cleaner or formatted something differently; here, the ABAP Test Cockpit specifically helps to perform a final quality assurance check. Of course, build pipelines can also be built based on these variants. This way, code running into the test system is automatically checked, cleaned up if necessary, and only then deployed accordingly.

IDE Actions

A very exciting development of recent years is the integration of ADT Actions into the ABAP Development Tools. This gives you the ability to integrate your own IDE functionalities or extend the IDE with specific automation techniques without leaving ABAP. Let's look, for example, at the previous section where we asked: Why should you build a factory and an injector? Generally, it takes a relatively long time to implement these objects in the system. We have to create the interface, program the actual class, and set up both the factory and the injector. That's quite a few objects that we have to create manually, which in turn have relationships with each other and therefore take a considerable amount of time before we can even begin the actual development. Since we developers are fortunately mostly lazy, we can, of course, automate this step. This doesn't necessarily have to be done with AI; it can also be done relatively heuristically with a simple structure and a corresponding generator. For this, you'll find MIA (My IDE Actions), an open-source project that offers several standards. One example of this is the generation of classes and their dependencies. This allows you to automatically generate all the necessary classes and, theoretically, specify optionally if you don't want certain objects. After generation is complete, the framework even takes care of activating the objects for you, so you can start programming directly and save yourself the recurring work.

Unit Tests

We also had a section on unit tests and how to build and further automate them, for example, by using injectors so that we no longer have to modify our actual source code. The same applies to regular tests: Once we've built the tests, we should definitely run them manually during development to repeatedly check whether our actual implementation is still working without errors. In most cases, this is limited to the local class with the actual implementation or, at most, to the package in which we are currently developing. The tests are quick to run and thus provide us with fast feedback so we can continue working on them directly.

The second pillar is the check when the transport is released. This means that the ABAP Test Cockpit can, for example, automatically execute and check all unit tests while we release the transport request. This is also available in the cloud as APIs, meaning we can integrate this step into build pipelines and have it automatically checked whether our code is still clean and the unit tests run without errors. A basic requirement for this, however, is that the tests are isolated and can be executed as efficiently as possible, without dependencies on the actual system.

Then we have the topic of the automatic execution of unit tests. This means we regularly run unit tests on entire packages or perhaps even the complete system to validate whether the system is still error-free or whether, for example, changes within the system have caused problems elsewhere. For instance, we might change an interface or structure, which in turn has no effect on our local tests because we have adapted and extended them accordingly. But perhaps someone else in their development uses exactly that structure, so their development would now encounter errors. Therefore, it makes perfect sense to regularly run unit tests beyond just one's own package to validate the entire system. For on-premise systems, there's the ABAP Unit Runner, a simple standard report that runs in the system and can be scheduled as a background job to automatically execute unit tests and send the results via email. Do you want to do this in BTP, for example, on a steampunk system? There, you'll either need a build pipeline or you can use an open-source project to trigger the automatic execution of unit tests and have the results sent to you via email. We generally recommend running the test regularly, for example, once a day, to ensure that all unit tests in the system continue to run successfully.

Here we have a comparison of both ABAP Unit Runners: one for on-premise and private cloud environments, and the other for the open-source version for the public cloud. The standard ABAP Unit Runner is started via a report, while the open-source version runs as an application job, since reports are no longer available in the cloud. You will find essentially the same or similar settings in both tools that you can use to schedule the job. In both versions, you can also enter an email address to receive information about the test run. The second screenshot compares the presentation of the test results: On one side, you'll find the email from the ABAP Unit Runner with the corresponding results, and on the other side, the email summarizing the results of the runtimes and the executed tests. Generally, it's worthwhile to always run an ABAP Unit Runner across the entire system to validate as many unit tests as possible without having to invest a lot of manual effort in actual maintenance. Instead, you simply check regularly whether the entire system and the unit tests running within it are clean and functioning without errors.

Conslusion

This brings us to the end of this entire series. Therefore, we want to summarize the three most important points once again: The importance of ABAP remains, even in the age of RAP and AI. A great deal of ABAP development will continue to be required to map the complete business logic within the system. Good design remains the responsibility of the developer. If clean structures are not established, both reusability and testability within the system will suffer. While AI can help automate, improve, and make unit tests more readable, the final decision should ultimately remain with the actual developer.

We have looked at pattern, which are an important component of ABAP architecture in a system. Correct application and usage help you improve testability and achieve it without significant system modifications. We have shown the standard pattern that can be used in everyday practice to decouple code and package it into clean objects.

The third point is testing. Unit tests should be the minimum standard for clean development. These help you to make later adjustments more quickly and have regular validations that help you extend code quickly. Regular tests running on the system help to check the entire system and identify and fix possible side effects as early as possible. Furthermore, even if testing is actually outsourced further in the process, tests help to accelerate the further development of the system. They provide a safety net for new developers, showing them how to read and extend the resources without fear of breaking anything.

Therefore, thank you for your attention today and throughout this series! On the left, you'll find the QR code to download various resources such as the presentation, materials, source code, and other articles used as references for this post. On the right, you'll find my LinkedIn profile if you'd like to connect, have further questions, or simply stay up-to-date with new articles and information. Therefore: Thanks for watching and see you next time!

Further references:
YouTube - Part 4
GitHub - Examples