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:-
https://open.sap.com/courses/wtc1
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.
Hoodoo Gurus
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.
Wrap-Up
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….
Cheersy Cheers
Paul