Folks,
In a brief moment of insanity I decided to sign up for openSAP course Writing Testable Code for ABAP. After completing the first week of the course I feel a bit like Vicky Pollard from Little Britain: “yeah but no but yeah but”. Let me explain.
Testing seems to be all the rage these days in software development. One might ask: why just these days, haven’t we been testing our programs all along? Of course (well, most of us did, anyway), but folks, it looks like we’ve been doing it either all wrong or not good enough.
The book Clean Code, which is to programming what Karl Marx’s The Capital is to communism, goes on about how the programmers are afraid of making improvements because they might break something. And if only we had a simpler, more efficient way to test our changes then we would be free to change the code without a fear of breaking it.
Now enter ABAP Unit Test which is supposed to be the best thing since sliced bread, according to Paul Hardy himself, as well as other SCN luminaries. Very well. I guess we need to find more about it.
In the first week of this openSAP course, we learned about the motivation to do more unit testing and had a small programming exercise to just dip our digital toes into the waters of ABAP Unit Test.
The “motivation” part can be nicely summarized by this slide:
This is just a small sample of the code being discussed in Unit 3:
The demo program this week was a convertor of Roman numerals (i.e. I, II, III, etc.) to Arabic ones (1, 2, 3). The instructors showed us how the test methods can be generated easily in the Editor. Note how the one_in_1_out method declaration here does not have RAISING clause. It’s because that line was just typed in by an instructor while the next two lines were generated automatically in the editor.
Later in the unit, this code is refactored (i.e. updated / rewritten with the goal to improve it) to remove some redundancies and improve readability. More test methods are added as well.
Tips and tricks wrap up the week nicely.
So far we are off to a good start with this course but I hope that somewhere in the coming weeks we will get to my main gripe with ABAP Unit Test: practical application in real life.
It seems that in any blog or book or TechEd session pretty much the same scenario is involved. It goes like this: oh, we have this object and it does these things. So we create zcl_something class and a do_something method with 3 lines and then a test method is generated, this is awesome, any questions?
OK, but here I am, working on yet another Jumbo ALV Report and how exactly will Unit Test help me? I just gather the data from a bunch of tables and then use SALV. I know the data selection will be fine (and if it’s not then it’s because the users forgot to mention some detail). ALV method call is rather difficult to mess up, it either works or it doesn’t and you’ll find out as soon as you run the program.
The most common ABAP tasks (at least for not-so-cutting-edge developers) either don’t really lend themselves easily to tiny unit-testable methods or that would not help to prevent any potential real life issues anyway. With ALV, most common issue is wrong specification, as I mentioned. With “read a spreadsheet and use BAPI to post a journal entry” the usual problem is the BAPI that returns mystery error messages that have nothing to do with the actual problem.
While it would be hard to deny that ABAP Unit Test concept indeed has some value, I can’t help but wonder whether it’s like many vendor solutions presented at TechEd: solving the problems that I don’t have.
Well, there is still time for the course to address this and hey, maybe we can use Unit Test to catch a bug in this slide? 🙂
It’s still not too late to join the course. The first assignment is due on March 21st 2018. After a fiasco with the openSAP Fiori course I was concerned about the time commitment. But, fortunately, the whole week 1 took just a single afternoon.
The course pace seemed adequate to me. Personally, I’d prefer a bit faster cadence but the slower speed is easier for the students with less fluent English. And there is always fast-forward.
The discussed ABAP code requires at minimum version 7.4. You can either use your own system or sign up for a cloud version (some cost involved). So far, however, I had no problem participating somewhat passively, just watching the videos and answering the questions.
The authors caved in under the participants’ pressure and posted the source code on abapGit as well: http://docs.abapgit.org/
The best part of these courses though is always in the discussions. Would you like to find out if there was 0 in Roman numerals or whether KISS actually stands for “keep it sunny, Superman”? Then join us in week 2!
P.S. For a slightly different take on the course read this blog by bfeeb8ed7fa64a7d95efc21f74a8c135
Image source: SAP, https://open.sap.com/courses/wtc1
In a brief moment of insanity I decided to sign up for openSAP course Writing Testable Code for ABAP. After completing the first week of the course I feel a bit like Vicky Pollard from Little Britain: “yeah but no but yeah but”. Let me explain.
Testing seems to be all the rage these days in software development. One might ask: why just these days, haven’t we been testing our programs all along? Of course (well, most of us did, anyway), but folks, it looks like we’ve been doing it either all wrong or not good enough.
The book Clean Code, which is to programming what Karl Marx’s The Capital is to communism, goes on about how the programmers are afraid of making improvements because they might break something. And if only we had a simpler, more efficient way to test our changes then we would be free to change the code without a fear of breaking it.
Now enter ABAP Unit Test which is supposed to be the best thing since sliced bread, according to Paul Hardy himself, as well as other SCN luminaries. Very well. I guess we need to find more about it.
In the first week of this openSAP course, we learned about the motivation to do more unit testing and had a small programming exercise to just dip our digital toes into the waters of ABAP Unit Test.
The “motivation” part can be nicely summarized by this slide:
This is just a small sample of the code being discussed in Unit 3:
The demo program this week was a convertor of Roman numerals (i.e. I, II, III, etc.) to Arabic ones (1, 2, 3). The instructors showed us how the test methods can be generated easily in the Editor. Note how the one_in_1_out method declaration here does not have RAISING clause. It’s because that line was just typed in by an instructor while the next two lines were generated automatically in the editor.
Later in the unit, this code is refactored (i.e. updated / rewritten with the goal to improve it) to remove some redundancies and improve readability. More test methods are added as well.
Tips and tricks wrap up the week nicely.
So far we are off to a good start with this course but I hope that somewhere in the coming weeks we will get to my main gripe with ABAP Unit Test: practical application in real life.
It seems that in any blog or book or TechEd session pretty much the same scenario is involved. It goes like this: oh, we have this object and it does these things. So we create zcl_something class and a do_something method with 3 lines and then a test method is generated, this is awesome, any questions?
OK, but here I am, working on yet another Jumbo ALV Report and how exactly will Unit Test help me? I just gather the data from a bunch of tables and then use SALV. I know the data selection will be fine (and if it’s not then it’s because the users forgot to mention some detail). ALV method call is rather difficult to mess up, it either works or it doesn’t and you’ll find out as soon as you run the program.
The most common ABAP tasks (at least for not-so-cutting-edge developers) either don’t really lend themselves easily to tiny unit-testable methods or that would not help to prevent any potential real life issues anyway. With ALV, most common issue is wrong specification, as I mentioned. With “read a spreadsheet and use BAPI to post a journal entry” the usual problem is the BAPI that returns mystery error messages that have nothing to do with the actual problem.
While it would be hard to deny that ABAP Unit Test concept indeed has some value, I can’t help but wonder whether it’s like many vendor solutions presented at TechEd: solving the problems that I don’t have.
Well, there is still time for the course to address this and hey, maybe we can use Unit Test to catch a bug in this slide? 🙂
It’s still not too late to join the course. The first assignment is due on March 21st 2018. After a fiasco with the openSAP Fiori course I was concerned about the time commitment. But, fortunately, the whole week 1 took just a single afternoon.
The course pace seemed adequate to me. Personally, I’d prefer a bit faster cadence but the slower speed is easier for the students with less fluent English. And there is always fast-forward.
The discussed ABAP code requires at minimum version 7.4. You can either use your own system or sign up for a cloud version (some cost involved). So far, however, I had no problem participating somewhat passively, just watching the videos and answering the questions.
The authors caved in under the participants’ pressure and posted the source code on abapGit as well: http://docs.abapgit.org/
The best part of these courses though is always in the discussions. Would you like to find out if there was 0 in Roman numerals or whether KISS actually stands for “keep it sunny, Superman”? Then join us in week 2!
P.S. For a slightly different take on the course read this blog by bfeeb8ed7fa64a7d95efc21f74a8c135
Image source: SAP, https://open.sap.com/courses/wtc1
- SAP Managed Tags:
33 Comments
