SAP Open ABAP Unit Testing Course – Week One
As I have said ten billion times ABAP Unit and TDD are the most important things in an ABAP developer’s toolkit that no-one ever uses.
SAP have realised this 100% lack of adoption and so have started a free Open Source SAP Course on unit testing in the hope of educating the entire ABAP developer ecosystem.
The link to the course is as follows:-
The rest of this blog is all full of jokes, but to e dead serious for a second, I would encourage every single ABAP developer who does not use unit testing (i.e. virtually everyone) to sign up to this course. You will not regret it, neither will your managers.
That out of the way, I can start being silly again.
MySAP, Not yours, MINE MINE MINE!
It is human nature to have a gigantic ego and think the entire universe revolves around oneself and I am not immune to this attitude. So, while it is 99.999% likely a co-incidence I cannot help but note that SAP made this announcement about a week after I wrote yet another blog about Unit Testing and how no-one in SAP ABAP world ever uses it, but they should.
Looking at the content in the first week I was very happy to see they had independently reached the exact same conclusions I had many years back, and some parts of the course even mirrored what I had written in my book. Of course I had based my conclusions on the work of many proven experts in the field e.g. Dan North regarding behaviour drive development, so naturally anyone talking about the same subject would reference the same sources and thus the end result would come out pretty much the same.
At the bare minimum this proves I am not totally barking mad, and have not been spouting nonsense the whole time. This presupposes SAP personnel are not barking mad as well, but let us for the sake of argument say they are not.
To recap what this is all about – if you start to use Unit Tests in your code it is a lot of work, but that work pays for itself, and your programs end up a million times better. Programmers in languages other than ABAP have known this for a long time.
ABAP programmers either do not know about the existence of such a thing, or are actively banned from using it by short sighted management. However I put it to you, ladies and gentlemen of the jury, that the instant an ABAP programmer starts writing unit tests for a real actual program intended for productive use, within the hour they will have found a schoolboy error in their code they would never have normally picked up until much later (e.g. end user finding it in production) after which they will become a convert.
However you cannot become addicted to drinking beer if you have never drank beer, or are never allowed to drink beer, no matter how good beer is for you. Some would say I should have picked something heathier than beer for my analogy, maybe pizza, but you get the general idea.
Morecambe and Wise
The history of UK comedy is littered with so called “double acts” the most successful of which was “Morecambe and Wise” which broke the record for the most watched UK television show ever for their Christmas Special. If you were to see that show today you would be very puzzled as to why that was the case, but times change.
The two gentlemen who are presenting the SAP Open Course on unit testing occasionally try to do a double act, doing a sort of forced conversation in the vain hope of it sounding natural. I suppose the problem is that most humour just does not translate very well between languages.
When I do a presentation for my UK or Australian colleagues I fill it full of jokes, but I take the silly jokes (and my jokes are silly in the extreme) all out when presenting to my German colleagues as they most likely would not take it seriously because there were jokes in it. Travelling around the world what you really want to avoid is offending the people in your new country where you live.
When I first moved to Germany I got one of the “culture shock” books warning me against doing English type things which would not go down well in Germany.
One such warning was that Germans are often horrified by the irreverent attitude that UK types have to work – this (work) is something that should be taken seriously and yet UK people keep making stupid jokes with alarming regularity. In one example a “C level” senior German banking executive was moved to the UK office of his bank where he was a director and attended his first board meeting in the UK. He was horrified by the fact any jokes were made at all during such an event, by the people right at the top of the company, let alone virtually the entire time. When the time came for the directors to pair up and climb inside pantomime horses to battle out on top of the boardroom table whether or not to demerge a subsidiary he almost had a heart attack. Apparently that is not the way it is done in Germany.
Fun Fun Fun, till her daddy takes the T-Bird away
In any event the presenters make much of the fact that introducing unit testing into the development process makes developing more fun. I happen to think they are 100% correct in this.
However the toneless delivery makes this unintentionally hilarious as in:-
Deadpan Man 1: “Was that fun?”
Deadpan Man 2: “Yes, that was much fun”.
This all being said in the same sort of serious tone you would use when telling someone your grandad had just died. Of course, this could all be intentional, in which case the joke is on me.
However let me make no bones about it – this course is WONDERFUL.
What is wonderful in particular about this course is that in the process of talking about unit testing a lot of other new ABAP technology is introduced e.g. some of the new “functional” constructs in ABAP and in particular ABAP in Eclipse. If you want to see some practical examples of why AIE is better than SE80 then just watch the videos in this course. You’ll end up running to the Eclipse website to download it as if it was giving out free money. You need ABAP 7.31 to use ABAP in Eclipse, and the benefit is only really for OO programming, but what a benefit it is.
In my blogs I like to stress I am not making this all up off the top of my head and thus quote assorted programming gurus, who have done this sort of thing for a long time with a great deal of success.
In this case they quoted Martin Fowler in regard to refactoring (improving the internal structure of programs without changing their behaviour and Robert Martin in regard to Clean Code (speaks for itself).
There was also a new name to me – Gerard Meszaros and his book on xUnit Test Patters. xUnit is the generic name for unit test frameworks – Junit is the Java one, ABAP Unit is the SAP one He says that if your code has no tests then all hope is lost – obviously that is not 100% true as virtually all ABAP code has no tests and it still works, but in regard to bug fixing or adding extra functionality he is right on the money.
On his website one of the quotes says “Unit Testing is hardly news” well not to the 99% of programmers who do not program in ABAP, but to everyone else yes, it is news, and wonderful news at that, to those that are inclined to listen.
Heads You Win, Tails You Win
In my presentations I give equal weighting to writing programs in such a way as you have a separation of concerns i.e. single responsibility theory, and unit testing. At first glance those two concepts do not seem to have anything to do with each other, so the latter is often ignored out of hand, but to me they are two sides of the same coin.
This course shows this concept as a pair of scales with unit testing in one scale, and writing testable code on the other scale. The scales balance out i.e. introducing the separation of concerns into your code enables unit testing. Doing just the first is good, but adding testing turns good into wonderful.
What’s the Name of the Game?
Now we turn to the naming conventions recommended. I was jumping up and down with joy when they said a unit test should follow the “GIVEN / WHEN / THEN” pattern as that is what I have been advocating from day one. They even echo my frustration with the thirty character limit for method names!
They say that the name of the test class should relate to the “given / when” part of the unit test – by this we mean a name like “ATM_FUNCTIONS” and then the test methods can complete the human sounding name of the user case such as “ATM_FUNCTIONS->WITHDRAW_WHEN_OVERDRAWN”.
The class (or whatever – remember you can use unit test on procedural code as well) should be called CUT (code under test) as opposed to its proper name. There is a good reason for this, but I cannot say it here, as it would ruin the multiple choice question at the end of the test where some of the alternate answers as to why to do this made me weep with laughter.
In regard to prefixes I am 100% aligned with their policy of having names like M_CUT to indicate member variables, and I_INCOMING and E_EXPORTING and R_RETURNING, and having everything else read like plain English.
One thing I would add to the first weeks course is that it is possible to have your test class inherit from CL_ABAP_UNIT_ASSERT and thus have slightly less code to write, an aspect given great importance during this course, and rightly so. The easier a unit test is to write, the more people will do such a thing.
Last, but my no means least, in fact the most important thing I got out of today, was a link to a series of YouTube videos from SAP called “Combinatorial Test Design”. The idea here is that it is impossible to test every single possible combination of inputs, if you have five import parameters with each one having ten possible values, the combinations become ridiculous. Luckily people have thought about this, and solved the problem, just like the travelling salesman problem has multiple solutions which do not involve “brute force”.
Those other videos are fantastic in and of themselves just in regard to how you should decide what to test. That seems like an insurmountable obstacle at the start of this journey, but once you are pointed in the correct direction it becomes obvious.
I will report back next week … but if you join the course yourself you will have no need to listen to me… so please do so….
I'm working in a consulting company, and I've been preaching Behavior-Driven Development for 4 years at my different projects, and the management didn't even understand how important BDD is. So, you're not alone at "barking".
I'm infinitely convinced that BDD is the next important step for the development, as much as important the object-oriented paradigm was when it replaced the procedural paradigm.
No doubt that SAP is developing or integrating BDD tools.
Even in my company, things are changing, I've been contacted 3 times these last 5 weeks by 3 different projects (versus 0 times these 4 last years).
By the way, I'm looking forward your next post about refactoring an existing program using test-driven development. This is of the highest interest to me, unfortunately I don't have enough experience on that topic to participate to your "public brainstorming".
I’ve read it in the books and blogs, but it is really starting to sink in with this course.
I couldn’t agree more with Paul’s assessment.
I'm doing the course and the one frustration I have found so far is that I am just not familiar enough with the functionality of AiE.
I don't do much ABAP in my job (BASIS Support), but it's obvious to me that beginners to AiE need an ABAP in Eclipse cheat sheet and they need to regularly and consistently use AiE (perhaps even ban themselves from the SAP GUI if necessary ?) to get familiar with it.
There is a lot of really good stuff in ABAP in Eclipse but it is also really well hidden. When you first install it there is a sort of tutorial, but it is rubbish and only covers the really basic functions.
Between now and June the two SAP systems I work on will both be upgraded from 7.02 to 7.50 so I can finally start using AIE for real, and yes, I will force myself to use it. That is rather like when the debugger changed and initially I hated the new one, it would have been so easy to change the setting to go back to the old one, but I forced myself to use the new one.
What I like in AIE is where you can highlight a block of code and turn it into a method, and it is clever enough to work out what should be local variables, and what the importing and exporting parameters should be, along with the correct type. That way you can break down really long blocks of good into a series of method calls.
There is also supposed to be something where you can automatically identify blocks of identical code and turn them into a method call i.e. the code is no longer duplicated. However I cannot find where that feature lives, it may be an urban myth.
To be honest, I had already signed up for the course but did not take a look at it yet, as daily business was quite time-consuming.
Your blog gave me last push I needed. Will listening to Video 1 I am writing this comment.
One of the issues initially in the course was that the source code for examples wasn't published. With the help of Lars Petersen, and the cooperation of Juergen Haymann and Thomas Hammer, this is being rectified, and we're hoping very soon to have all the examples in a Git Repository.
I was delighted how Juergen and Thomas so quickly and enthusiastically got on board with this.
(However, Paul, you may not be Barking, but I'm fairly sure you're Upton Park. That's one stop short...)
just one side note to your comment
That's not possible. CL_ABAP_ABAP_UNIT_ASSERT ist final.
What you probably mean is it's predecessor CL_AUNIT_ASSERT? With that it was indeed possible to inherit your testclass from it. I was also used to this practise.
I once complaint about that's not possible to inherict from CL_ABAP_UNIT_ASSERT to a SAP internal developer. He said that this desing choice was made deliberately. But I forgot the exact reason why. I think it was something like if customers inherit then SAP loses the ability to freely add new assert methods without breaking.
Yes, in other languages you have your test class inherit from the standard assertion class. SAP followed this practice and then "improved" it.
Even after all this time I don;t really think the developers at SAP "get" object oriented programming. You will note that all classes on creation default to "final" until you remove that tick, and you get warned when your local classes are not final.
If they do not understand by now why that is a bad thing, they never will.
I don't thinking adding new methods would break the subclasses, but removing methods from the parent class or changing the interface by removing parameters or adding new mandatory ones would. However if you follow the "open-closed" principle properly you would not do either of those things.
I think their case was, if they add a new public or protected method ASSERT_MONSTER and a customer already has it in a subclass then it will break. But I would be totally fine with that. If I inherit from something I have to live with the consequences.
Instead they propagate the use of ASSERT_THAT where you can implement custom checks with the interface IF_CONSTRAINT.
That is indeed the gamble you take when inheriting from a standard SAP class, or indeed any class you do not have control over.
I think the main reason for wanting to inherit from CL_ABAP_UNIT_ASSERT was not to add new methods but to make the code in the test methods shorter so you can just say ASSERT_THAT rather than CL_ABAP_UNIT_ASSERT=>ASSERT_THAT.
That seems trivial but even in the course the presenters made much of having the test code as compact as possible.
In case anyone is interested - link to YouTube videos on Combinatorial Test Design.
I finally got around to watching those videos. I watched the first one the very first day, but there were five more, with the last one the longest (and most interesting).
The "all pairs" thing is about when you have lots of input variables and thus have ten billion combinations and there is a tool to get this down to a manageable number. I get the general concept but have not got my head round the maths just yet.
It is like in "The Dark Tower" by Stephen King when most of the characters cannot grasp what a prime number is, and that seemed strange because it was so obvious to me, but now I find myself with an exact same sort of mental block. It is like when I was 16/17 and I decided in my infinite wisdom to take an A level in Pure Mathematics with more Pure Mathematics. I just scraped through but in retrospect I should have chosen history or some such.
I did get the highest ever score at my school for my A level in Economics (boast boast) which sounds good on face value, put I would point out that the year before me some girls at my school taking that exact same exam went on to become Bananarama. One of them is now married to Andrew Ritchie from WHAM! as I understand it. So I am not sure if saying that one paper I understand how the economy works better than ladies who sang "Love in the First Degree" is actually anything to boast about. They made a lot more money than I ever will!
Going back to unit testing and all pairs analysis, what I do know is that if there is some sort of algorithm to generate the smaller number of test cases based on the input parameters then OF COURSE you can do it in ABAP rather than a third party tool. The reason for this is because ABAP is a programming language. It might not be easy, for all I know it could take two years to write, but it would be possible.
I might as well share the notes I made about the "combinatorial test design" videos.
The problem is all about what to test. A lot of people really struggle with this.
The first recommendation is to get a list of "use cases" which often equate to user commands available on the screen, or if there is no screen the public methods of the API. Those are user commands of a sort also but called by a machine generally.
These user commands have one or more input parameters that are "real" i.e. input by a real person, and often several that are "fake" e.g. configuration data (which you mock) or input from helper objects (which you mock).
The problem then is that each parameter can have loads of values, and if there are lots of parameters you can have ten billion combinations, and you cannot test them all.
One thing research has discovered is that most bugs live at "boundaries". I know first hand a piece of software I used to handle the hire purchase arrangements of truck drivers. It would automatically process every payment but the last, no matter how many of few payments there were. There was also an invoice program that created invoices for every delivery expect the last one.
So if you have an application that expects values between 30 and 50, create a test case for 29, and another for 51, as they are the values by far the most likely to expose a bug.
Those are called "equivalence boundaries" you will be happy to know.
Then, when there are up to four parameters you can make a decision table where every possible combination of inputs and outputs are covered. They showed a spreadsheet for this, but that is not a complex concept.
As I said above the "all pairs" tool is far more complicated. I have downloaded a bunch of stuff to see how the math works but the concept is clear. they gave an example of several input fields where you ended up with 3 x 2 x 2 x 2 x something and the total number of possible input variations was about 600, but the "all pairs" tool whittled this down to 14 and claimed that was enough to give you proper test coverage. This is because the values are usually inter-related to a greater or lesser extent, and so making sure pairs of values are covered as opposed to individual values reduces the combinations.
They also group similar things - in the example GT was said to be close enough to GE so you did not need two test cases.
I will write more on this when I work out the exact algorithm.
I have found a reallu good example that explains how "all pairs" works.
Efficient Testing with All-Pairs
Prepared for STAREast 2003 International Conference on Software Testing
So of course - even though I am given a working program which does it automatcially I need to re-writre it in ABAP and that is what I am doing. I will let you know when I am done, it is not easy, which makes it fun.
PERL is a new language to me and seems closer to machine code than the verbose language which is ABAP. Some say that the verbose nature of ABAP is bad, but in the PERL source code here the authir has to document every line of code with a comment, otherwise you would have no idea what was going on.
I am with Donald Knuth here - the idea of programming languages is that the code can be readable by a human, like it was an English sentence, and then compiled so a computer can understand it at run time. Is that such a radical idea?
That is why I sometimes feel the new ABAP constructs need to be wrapped to tell the person debugging the program what in the world is going on.
All programming languages are the same. Turing proved it. 😀
Completely agree with Christian about cl_aunit_assert class. On SCN there was a comment, why SAP has replaced it with cl_abap_unit_assert.
By the way here is a nice YouTube playlist about features of abap in eclipse.
I hope SAP will keep it updated.
Paul Hardy I hope this urban myth will become reality or already is?
My fav comment from one of the presenters in the discussion forum for this week 1:
"There is no magic test framework"
Very true. Unfortunately.
Since I've taken the TDD course, I'm experience daily profound regret that I didn't have the course available 20 years ago.
It's awful. I'm enhancing program I wrote 6 months ago. and I'm having to guess that my fixes will work and won't break anything else.
When I was a child I took one look at pickled red cabbage and decided I did not like it without even trying to eat it, based on its apearance.
These days it is my favourite food.
Unit Testing / TDD is the same. In this case it is difficult to get the extra time you need to get started in work time,and most people do not have the spare time to experiment.
This is a pity. I bet most people reading all these blogs have not yet tried to do this in their day to day work. If they had they would either be pleasently surprised or be able to blog about why this just does just work for them and here is why,
It works for me, my application I am working on has had its designed changed for the better immeasurably just because of the test business, and the regression tetsing is just a very welcome extra I get for free.