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. The results in terms of delivery were amazing, we were able to deliver new features to production weekly, solve issues in hours and always doing it with the confidence that (good) automated tests can give you. We also got rid of the old Maintenance AND Project landscapes. We hade one landscape composed of a development, a quality, a pre-production and a production system.
At somepoint 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 technolgies, I was not fully statisfied 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.
Following some principles in continous 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, 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 and 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 now able to navigate through our code base, understand wich 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 preciselly which test has failled 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 ;).
There might be some technical elements that still prevent the ABAP of achieving full continous integration. But for continous 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 the possibility of remotely execute tests so we could push something to quality knowing our tests were passing. 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.
As the CLI was built using Node Js, it should be fairly easy to create pipelines that use it.
Watching tests while I code
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.
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!
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 breavery 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!
What do you think? Leave your comments below!