Embracing ABAP TDD as a standard development practice

Introduction

Last October, at GrainCorp, we went live with CropConnect self-service Croptimiser. It allows our Growers to optimize their grain quality at no extra cost. You can find more details on the same here – https://grains.graincorp.com.au/croptimiser/. The project was a huge success. Our growers are happy and so we are happy.

Performance improvements is one of the key challenges that we faced to achieve this project. The code has to perform all the Croptimiser calculations within a few seconds and also should be able to bear the load. We had to make code changes multiple times to achieve this performance and at the same time should not break the business logic.

One of the key factors that helped us achieve this project in a short period with highest quality is the ABAP TDD(Test Driven Development) approach.

Embracing TDD(Test Driven Development)

A simple definition of TDD(Test Driven Development) would be – it helps us make code changes without worrying about breaking the existing code logic.

In spite of numerous benefits of TDD not many developers are embracing it. I would like to discuss the benefits, challenges and myths related to TDD.

What is the core benefit of TDD?

Making code changes with confidence is the core benefit TDD offers.

Imagine you wrote 1000 lines of code, perfectly modularized, manually unit tested all the 100 test scenarios and ready to move to the next environment. As always, right at the end our beloved end users/BAs come up with a new requirement. In a traditional process we have to make the code changes  and manually retest all the 100 scenarios again and the additional new scenarios for the new requirement in the development environment before we can move the changes to the next environment.

But if you have followed TDD, you would not have to go through the manual testing. You can run all 100 test scenarios in a few seconds. If any of them are failing we can fix and rerun the tests again in a few seconds.

It need not be a new requirement, maybe you need to make changes for performance improvement. You can not risk spending so much time to rerun all the test scenarios manually every time you make a change for performance improvement. That’s where TDD helps.

Is it not time taking?

It is true that it takes more time to write code in the ABAP TDD approach when compared to the traditional way. But it definitely takes less time when compared to writing ABAP code in a traditional way and manually unit testing it every time you make a change assuming unit testing is done every time you make a code change.

The coding looks complicated and I never worked on interfaces.

An ABAP developer with more than 15 years of experience made this statement.

I am sure you did work on interfaces. Interfaces are the building blocks for BADI or OData frameworks and I am sure most of the ABAP devs would have worked with BADIs at least.

We are not on S/4HANA. Is that ok?

Even without S/4HANA you can still gain most of the benefits of TDD. You can run the automated unit tests in the dev system after every change or in the quality system periodically at package level or for multiple packages.

Should we wait for S/4HANA?

With S/4HANA you get gCTS(git enabled CTS) which in addition to ABAP TDD helps run automated unit tests post importing a commit to the quality system. If the unit tests fail gCTS can automatically rollback the change.

To gain all these benefits you have to have some TDD code already in your system. And obviously you can not start writing TDD unit tests overnight for all the existing code when you move to S/4HANA. So, start now so that you can enjoy the benefits now and earn more rewards later.

So, what do you suggest?

Give it a try. Start implementing TDD in small projects. Maybe in projects where you are performing most of the work. That is what I have followed with Croptimiser. It was a bit easy to implement TDD as I did 90% of the core work. Once you are comfortable, encourage your team to try the same. Come up with a team approach. Even better, sit with your testers and check if you can add any of their test cases to your ABAP TDD unit testing. Add TDD into your coding standards. Have a road map for S/4HANA. All the best…!