ABAP Unit tests, monitoring and integrating them into pipelines

[felipe_dimmu23]

Somewhere in the past, after a year practicing Clean Code and TDD as a team, we were able to cover around a third of our code base with automated unit tests. At some point though, I began to wander what wasn't being covered by tests and began to notice we would often break some tests and not notice it. And although I could see an universe of tools to help write, execute and monitor tests in other technologies, I was not fully satisfied with what we had in ABAP.

Since ABAPGit came out, many open source solutions in ABAP started sprouting in Github. And now, after taking so much from the open source community I decided to give something back and hopefully motivate more teams to onboard their own journey towards the excellency modern software development demands.

A monitor

Following some principles in continuous delivery and DevOps, we would from time to time deliver monitors of some of our applications and interfaces to help our support team to be pro-active and solve issues before they were reported.

However, we lacked something for ourselves, something that would help us nurture our code base to the better, find the corners that were not tested and allow us to be sure we were always green (as in all tests passed). Also, I knew having something visual every day would engage ourselves more into keeping things clean and green.

Thus, I decided to start working in a monitor just for that. And so, our ABAP Unit Dashboard, or ADASH, was born:

A cut from a screenshot of ADASH. All data is fake

With it, we are able to navigate through our code base, understand which change broke what and how we are looking in terms of coverage. We can re-execute the tests on a specific package (or class) on demand too. With the Cli (see below), we are able to set group of packages so we can have different teams monitoring different domains. And at last, we can take a look at precisely which test has failed and why:

Peeking into a class tests

And all it takes to start the monitor is a

adash mon -s dev

provided that you had setup your dev system, of course ;).

The road to ABAP CI/CD pipelines continues

There might be some technical elements that still prevent the ABAP of achieving full continuous integration. But for continuous delivery, a lot has come up together in the past years. ABAPGit and ABAPLint are some examples on that direction. One thing that we were missing though, was integrating our tests in our internal Gitlab pipelines. The idea came from our front end developments, we had front end tests and would deploy the application to the backend if they passed, however we would do it regardless of the backend tests failing or not and so our CLI (Command Line Interface) came to be.

 

Testing packages!

As the CLI was built using Node Js, it should be fairly easy to create pipelines that use it. And again, after setting it up, all it takes is a

adash testp yourPackage -s dev

to execute the tests remotly and get a quick feedback,

Bonus: A watcher

All credits to the people behind ADT and the plugins for VS Code, you have freed us from SE24. Without it, proper OO, clean code and test driven development would not be possible. There is one feature I really enjoyed while working with Javascript. A lot of test frameworks come with the ability to "watch" my code and see my tests brake or fix as I go. Realizing I could emulate something similar with what I had already built, I thought...why not?

Watching tests while I code

A fair warning

All is available and free through the ADASH Cli, keep in mind that this is by no means a commercial tool, nor one that reached (in my opinion) a V1.0 maturity. There are some bugs to fix, tests to implement (ohh the irony), and functionalities to add. I know summary tiles and vizchart graphs showing history of test and coverage over time are on the make, more than that, I was hoping to engage the community into collaborating to it.

This is but a tool, helping us to have a collective ownership of our code, and it runs the tests we wrote. It doesn't, by any means, test things "automatically" or statically like ATC.

Conclusion

During a decade I would see and envy other languages ecosystems and communities, how vast their collaboration was and how easy it was to consume thousands of hours of other peoples work to greatly increase our own productivity. But, in the past 5 years I was able to see how fast our own ABAP community grew and how that started to become true to us too. UI5 came to the rescue in the front-end part and in the end all languages have advantages and disadvantages.

ABAP is renewing itself, as are we, who use it. XP Programming, Test Driven Development, Continous Delivery, Continuous Integration and DevOps are just some of the words that describes modern software development (and its lifecycle). And while its full adoption might be technically restricted with ABAP, there is huge difference of what we can achieve now and what we could achieve 20 years ago, and a lot is coming together thanks to this two way road called open source.
It is true that projects and products that use ABAP are generally restricted by rigorous processes and tools...

But, from my experience, the barriers to TDD (for instance) are more personal than technical or managerial. It is quite easy to find excuses and continue doing things the same way. It takes bravery to scrap years of function module experience to dive into OO, Testable Design and Test Driven development. ABAP for sure is ready for us to step up. Now we even have ABAP in the cloud! I hope projects like this inspire you to be better, as much as the open source projects I used inspired me to be better.

What do you think? Leave your comments below!