Jelena Perfiljeva coined the term “ABAPosaurus” in her recent blog post ABAPosaurus Takes openSAP Course and it’s a fitting term for me as well. I’ve been in programming since 1985, the first 15 years with PL/1 on an IBM-mainframe computer followed by ABAP starting in 2000 when the company I then worked for (Kodak) switched to using SAP for almost everything globally.
So, long story short, I’m very much into procedural programming and (still) have a hard time wrapping my head around all things ABAP-OO. Nowadays, I don’t do a lot of programming myself and what I do is usually fairly trivial stuff along the lines of “select some data”, “enhance the selected data somewhat” and “create an ALV output from that”. My main reason to tackle ABAP-OO is to at least get some experience and to build a “passive” vocabulary in order to understand and review code written by others.
So, I decided to sign-up for openSAP’s ABAP Unit Testing course and have thus far worked my way through the first two weeks of lectures. I have access to a sandbox system at work so can try my hand at the exercises and play a bit with the provided code. One of the biggest benefits the course has is to learn about (for me!) new ABAP-constructs like DATA and VALUE to create and fill variables and the like on the fly.
Having said that – and even after reading the other blogs about the course like e.g. the one from Paul Hardy (here) or his comment on Jelena’s post (here) – I’ll still need “some” convincing that Unit Testing will in the foreseeable future become helpful to what I do. Here is my reasoning:
Whenever I write a new program, I do so in stages to a) always have executable code without any syntax errors and b) know that what’s already in the code works as it should. This is obviously not test driven development as I always have the code first, but it’s not that much different either as I don’t wait with testing until I have the complete program written. Here are the steps I usually take:
- Create a rough mental or written outline of what I need
- Start with an empty template via code completion which contains the main definitions, sections and routines I typically need
- Define the selection-screen and “play” with its look and feel until it looks usable
- Add the data selection for the “main” table and make sure that it works by executing the program with a break-point at the select-statement and checking the internal table’s content immediately
- Tweak the select if and as needed to get the expected result for the selections requested
- Add (or already have) the rudimentary logic in the code to fill the internal table for the ALV-output and trigger the output (this then makes it easy to see if the selection works and there’s no longer the need for debugging the SELECT)
- Add more logic to fulfill the requirement “in stages” by adding some code and executing the program to always see if the additional logic gives the expected results, like e.g. filling more of the ALV-columns with the correct data.
- Clean-up the code as needed, add documentation, text-elements and the like
So, I’m wondering if this approach is really all that different from test driven development?