Embracing ABAP TDD as a standard development practice
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…!
I am horrified (but not surprised) that an ABAP developer with 15 years experience did not know what an interface was (in the ZIF_ SE24 sense of an interface). The concept has not only been in SAP since the year 2000, but was even there (in SAP) before in Business Workflow.
I would say in such a case that developer does not in fact have 15 years experience, bur rather one years experience, repeated fifteen years in a row i.e. never learn anything new.
I also find it odd that people are linking ABAP Unit to S/4HANA given that ABAP Unit was there before S/4HANA was even invented. There is no link at all. Therefore you can start with TDD straight away.
I have written more blogs on TDD/ABAP Unit than there are stars in the sky, and there is so much resistance it makes one want to give up but I never will.
What I will say is that it is a lot of work to get your head around the concept but once you do you will never go back. It seems like more work - and it is in the short term - but over the long term it is vastly less work due to the gigantic reduction in debugging/troubleshooting every time you make a fix/enhancement. But how many people can think in the long term?
It is a Matthew Billingham says - "no-one who was ever forced to learn the piano as a child every regrets it as an adult"
Quality systems are usually used for quality assurance, eg. business performs validation before changes are moved to production. If choosing to frequently move work-in-progress code to the quality system, as in TDD, the quality system becomes a moving target, making it unfeasible for quality assurance.
Basically, you'll have a development process which promotes breaking the quality system.
Lars is 100% correct.
I have never run a unit test in QA ever. The thought never even occurred to me,
This is for the development system, You run the unit tests and only when they all pass do you move the code to QA.
At that point even if you did run the unit tests in QA you would not get a different result than in in DEV because if you had written the tests correctly there would be no dependencies e.g. database access and the like.
My biggest issue with TDD that I have is when the requirement is not clear, undefined o even wrongly defined and sadly I would say that is 80% of the cases (and I think I'm being gentle). And I'm not talking abount little tweaks really code changes.
Having to change so much your production code and also your ABAP Unit is very frustating, that is why I don't use TDD. I do use ABAP Unit but afterwards.
I realize the benefits of TDD but IMO is really tied up on how good your business users are.
Now you might think that the total and utter lack of specifications is just a burden you have to bear where you work, but it is everywhere, all over the place.
To recap the problem - one of the following three:
No Specification / Unclear Specification / Utterly Wrong Specification
This is normal. Every developer has to deal with this. Every single developer in the world, and not just in the ABAP/SAP space.
So why is TDD so popular in non-ABAP world if the other developers have the exact same problem?
The point is you write the tests based upon your best guess as to what the specifications are. Even if you did not use TDD you would have to write the production code based on such guesses. I know I have many times.
So with TDD you have a series of tests based on your guesses and you can be 100% sure the production code fulfills those guessed assumptions. Without TDD you have code you think fulfills those guessed assumptions.
Then in either case you show the result to the business analyst/end user at which point they (hopefully) tell you what the actual business requirements are.
Without TDD you then change the production code (or delete it all and write it all again) to meet the new (often radically different) requirements and hope it works.
With TDD you have an extra step - you have to change the tests first which as has been noted could in the worst case mean deleting them all and writing a whole new set. But if you have to do that then that means you have to delete and recreate all the production code as well.
It is more work (double work as the Germans say) but the point is you move from having production code that 100% meets the guessed requirements to code that 100% meets the (hopefully) correct requirements.
And it is always possible that some of the original requirements were correct. Stop laughing - it might happen!
Anyway - the point I am making is that the whole thing is a mindset change. For a new requirement (right or wrong) you write the test first, for a changed requirement you write the test first.