There’s a MONSTER under my bed!
Writing a Book for SAP Press – Part Three
Table of Contents
Background
Unit Testing
Static Code Checks
To Be Continued
Who’s that watching Benny Hill – Is it a Monster? Is it a Monster?
The other day I published my second blog about writing a book for SAP Press - a book which primarily focuses on monsters but may possibly illustrate that subject by talking about all the latest ABAP technology.
http://scn.sap.com/community/abap/blog/2015/04/07/whats-that-coming-over-the-hill-is-it-a-monster
My old matey Martin English – whom I shall be having a quick drink with at the Mastering SAP Technology event in Melbourne at the end of May 2015 – asked if I was ever going to shut up about this? Sadly the answer is no, not until I have finished documenting the thinking behind everything in the book, so ha ha ha ha, hard luck.
He also wondered if I was going to put all the best bits from the book online. Now that would be silly. I often do silly things, virtually all the time in fact, but I am not going to do that one. The author of the recent book “SAP Nation” Vinnie Mirchandani wrote that he likes to put 20% of the content of his books online. In my case SAP Press already give out a sample chapter, so that is enough to be going on with. Instead I am going to add in material that was cut out of my book for reasons of space.
Chapter and Verse
In the last blog I mentioned the thinking behind the first two chapters. To summarise…..
The first chapter was all about Eclipse,
Because that is so Cool and Hip.
The second was on new ABAP Features,
To show I practice what I preaches.
Going back to prose for a second I was trying to follow the logical flow of writing a program. The first step is choosing your development environment; the second is to make sure you are aware of all the new ABAP features at your disposal. The third step – and therefore the third chapter - is something more often seen in non-ABAP languages and is something I like to waffle on about like a broken record till you can’t take it any more.
How evil are YOU?
The first thing you are supposed to do when writing a new application is to write the tests before you write any actual code. A few years back I wrote a whacking great blog on the subject:-
http://scn.sap.com/community/abap/blog/2013/04/18/are-you-writing-evil-abap-code
I am an enormous fan of test driven development in general, and it’s manifestation in SAP namely ABAP Unit. This is not just an academic position, I write unit tests for all my new developments and retro-fit them when I make changes to old programs, and this has saved my bacon many times. What I mean by that is the automated tests point out to me the schoolboy errors in my programs well before anyone else can find out about them and laugh at me / sack me / whatever.
Yesterday, for example, I spent all morning writing unit tests for a business critical program. I would say as a result I made the application much more stable, but a lot of people would say I was wasting my time when I could have been doing something worthwhile. How can this be? Why, when some people realise what ABAP Unit is instantly say “oh my god, don’t do THAT!”?
Is this the right room for an argument?
The ABAP Unit framework came in with ECC 6.0, which entered ramp up in October 2005. So we are looking at something that is ten years old in the near future. If this approach and supporting framework are as good as I (and all the experts I keep quoting) keep saying they are then you would think that everyone would be using this by now, and it would have no place in a book about the „latest“ SAP developments. Yet it has been my experience that in fact very few ABAP developers use ABAP Unit at all and a surprising number are utterly unaware of its‘ existence.
Even worse, some development organisations have an outright ban on this approach. We now look at two common arguments against the test driven development methodology.
There are two possible groups who can raise objections:-
· The developers themselves
· IT Management
Developers Won‘t Use It / Don’t Like It
At a demonstration at my company in 2013 none of the other programmers had heard of ABAP Unit and my boss asked me if this was open source software like ABAP2XLS that I had found somewhere on the SAP Community Network web site.
So one reason ABAP Unit is not used as much as might be expected is that a lot of people don‘t know it’s there, but the other side of the coin is that even when they do know about it you have the „you can lead a horse to water but you can’t make it drink“ problem. This is when the developer has a quick look at the tool and decides it doesn’t add any value and so disregards it.
When I started looking at test driven development a few years back I thought “what a waste of time, 95% of my programs involve reading things from the database and updating other database tables, and then showing the result to the user, if you fake all of this using stubs what in the world is the benefit?”
It turns out that the remaining 5% of code is riddled with bugs and this shows up instantly during unit testing. If you don’t believe me, try it yourself and you will most likely discover the same thing on the very first attempt. Many times I have thought “this routine has only three lines of code – so it cannot possibly be wrong“ – yet it was. In the ABAP2XLS project unit tests have started to be introduced, and there was a test on a three line method that failed – a null value was passed in and the test was that a null value was passed out, except that it wasn’t.
Just to be clear about this, I think that any developer using test driven development and ABAP Unit for the first time on an actual program they are writing for productive use will discover a bug they would not normally have found until weeks later- within the first half hour, quite possibly the very first time you take the test • unit test option.
This is literally a product that sells itself (if you can get someone to try it), so developers are easy to convince, but then we come to the next barrier, which is management...
Some Things Just Can’t Be Tested
How can you do a unit test on say, a part of a program that has a pop up box requiring user input? It’s impossible surely?
Well yes, you do not have a user. The trick is to alter the program being tested so that all user interface code and screens (the user interface layer) is in its own class. Unit tests cannot have any user output at all, not even messages, so a unit test cannot call any code which might do a CALL SCREEN or a MESSAGE statement.
SAP have not yet worked out a way to reconcile the “call screen” statement which all GUI user interfaces revolve around with OO principles. The recommendation is to put your screen in a function module, and then wrap that in a method so it can be subclassed for unit testing. That’s a lot of work when creating programs when just doing a CALL SCREEN or MESSAGE statement is so easy, for what seems like zero return and you may wonder – is it really worth it? I would say yes, the benefit of being able to test something you could never test before (a part of the program which involves user interaction) outweighs everything.
It Takes Too Long
The only way to make your programs absolutely bullet-proof is to make sure every single line of code gets tested – every variation of every IF statement, every CASE statement etc.
This really means the amount of tests you have to write is directly proportional to the amount of production code you are testing, and because of the code needed to set up the tests and evaluate them afterwards that proportion is greater than 100%.
There are tools to reduce the amount of test code, but it could still be the case that the amount of test code you need to write is at least equal to the amount of code in the program being tested, probably more. So when you are done there will be more test code than production code.
You try telling that to an IT manager and see what happens. It is difficult enough getting a program working before the incredibly tight deadline as it is, and now we are talking about doubling the amount of code. That means doubling the development time doesn’t it? Doubling the cost? That would imply missing the deadline and coming in well over budget.
If that was true then test driven development would never get off the ground, management would ban the entire concept the instant they heard about it – and some managers do just that.
Here are two arguments you can bring to bear to counter the – inevitable – criticism from people who have never heard of the concept of automated unit tests.
Unit Testing’s impact on maintaining existing developments
If someone were to ask “what is it exactly that programmers do?” after the swearing and derogatory comments died down the answer would probably come back as “they write new computer programs”. That sounds correct but anyone who has spent any time at all programming would realize the correct answer is “a programmer spend 5% of their time writing new programs (the interesting bit) and 95% of their time fixing bugs and enhancing existing programs”.
Development time vs Maintenance time over total life cycle
The development manager at our company was amazed to hear this, he thought I had made this up after being hit on the head or something, and only after every programmer on the team voiced their agreement did he come to the conclusion this might possibly be true.
A huge debate raged about this on the internet – people were saying that if you spend 95% of your time fixing existing programs then it must mean the programs were really badly written in the first place.
I used the analogy of the SAP HR module – every year in every country the governments change the laws and taxes governing payroll, and SAP has to modify their HR / Payroll programs to reflect the legal changes. It does not matter if the program was written badly or well – the law is the law and SAP has to change these programs, every year, forever. Thus, over a (say) 20 year period the percentage of maintenance effort as opposed to the effort of originally writing the programs climbs to near 100%.
Not everything changes that much, but we have found that any custom program in heavy use is subject to a non-stop stream of enhancement requests from the users. No-one is ever content – it is human nature and good job too, otherwise as programmers we would be out of a job – and so it could be argued the only reason you are NOT getting lots of requests to add new features to any given program is because no-one is using it.
If you accept that you will spend the vast bulk of your working life maintaining existing programs, then your main day to day problem becomes this – how to change an existing program that works perfectly without breaking it.
That’s where the unit test framework comes in – traditionally you change one area and then break other areas, and either people have to manually test the vast array of different things the program does to ensure nothing has broken, or the end users find out in production, and you have to spend hours debugging to find out what in the world went wrong.
Nothing is ever a 100% silver bullet, but with automated unit tests you can see if any area of the program unrelated to your change has broken, five seconds after making your new change.
The argument is that the amount of time saved on maintenance over the entire lifecycle of the program more than outweighs the extra time needed at the start. The problem is that accepting this involves thinking in the medium to long term instead of just the immediate short term, and we seem to be living in a short term focused world.
It might be that you are a start-up and if the program is not finished really quickly then the company will go belly up and there will not be a medium or long term to worry about, in which case you might think the whole argument would fall on its face. That brings me to my second argument against test driven development taking too long.
Unit Testing’s impact on new developments
Traditionally if you had a really large development, you could only be sure it was working properly when you had finished a large chunk of it, and were then able to run it in the development environment yourself, doing what you end user was supposed to do and seeing what happened. Usually a short dump was the result, or all sorts of weird results, certainly nothing like what you were expecting.
The test driven development methodology turns this on its head – by the time you get to that stage you have a big bunch of tests covering every line of code you have written, so if something is wrong you will have found out and fixed it long before the stage where you try and simulate what the end user would do.
A lot of the time the development system has no meaningful data, or is not hooked up to an external system, so you wait till the program is in QA before you can do a meaningful test, then you (Or the testers) find the problem, and you fix it in development and have to move it to QA to try again. If you could resolve a lot of those problems before the program got moved to QA you would solve a tremendous amount of time.
So my argument would be – by writing twice as much code you actually get a working product (program) out of the door faster. That may sound difficult to believe but all you have to do is try this approach once and see if what is descried above is true or not. I would hope you would be pleasantly surprised.
Code Quality Street
If the third chapter was going to be on the sort of dynamic testing that is represented by Unit Tests, then the fourth chapter would cover static code checks.
During upgrades SAP are always telling us to get rid of as much custom code as we can – that is primarily because so much custom code never gets used after a very short while, but this can be perceived as an attack on the quality of us “customer” programmers.
It is easy as a non-SAP developer to get all offended by this, especially since standard SAP code is 100% visible and sometimes schoolboy errors are spotted by us “customers” which then get corrected by OSS notes - leading to the observation “people who live in glass houses should not throw stones”.
SAP do have a point however, many companies have got into serious trouble over custom code quality, the reason is unclear but possibly this is down to the fact that a lot of programmers started without any formal training in ABAP (I am an example) because they knew other programming languages, or because they were experts in other areas of SAP (or even the business) and migrated to ABAP programming, or in my case because I was in the right place at the right time.
A Code Inspector Calls
We are all familiar with static code check tools like the extended syntax check and the code inspector, but do you ever find that some of your developers either can’t be bothered and/or think the whole idea is a waste of time?
I once recall being told by a programmer that a gigantic program was maintained by the whole programming team, and the person telling me the story got to make a change about every four months. After they had made their change they did a SLIN/SCI exercise and found dozens of warnings and errors that had popped up over the intervening period when other programmers who did not use the checks had made changes. The icing on the cake was that the programmer who did use the code inspector was not allowed to fix the other problems because they did not relate to the change at hand.
SAP had clearly thought about this sort of situation and as a result the ABAP Test Cockpit was born, which became the subject of my fourth chapter. A lot of people find it difficult to get their head around what this actually is and what the difference between the ATC and a code inspector with more checks is.
As mentioned just now, some developers don’t bother with the static code check tools. They sometimes justify that by saying that those tools can come up with so many false positive errors that you can’t see the wood from the trees.
Pragma – we’re all Crazy Now!
You may have seen the t-shirts where you have the familiar picture of a monkey on all fours behind a monkey walking on his hind legs following a Neanderthal behind a human who then turns round and says “you lot - stop following me!”
That was all about evolution, and in regard to false positive errors SAP’s handling of these has evolved from “Pseudo Comments” via “Pragmas” to “exemptions”. All three follow the same premise but become more informative each time.
With a “pseudo comment” in the code the warning/error went away but all a later reader of the code knew was that the developer thought this was not a real error. The practice of some developers to use the technique to suppress every single reported error did not help matters much either.
With “pragmas” you could have a real comment (on the same line) after the pragma to say why the error is being suppressed. That was a big step forward, and with exemptions (such as you find in the ATC) you can write a war and peace length explanation as to why this is not a real error.
Big Brother is Watching YOU
The ATC is based on the idea of some sort of “Quality Manager” with horns and fangs who has to keep the programmers in line by beating them with a stick every time they make one their numerous mistakes.
This is the so called “four eyes” principal where a different person to the developer reviews the code for correctness, and is all well and good, but a proper “peer review” system where another programmer has to check the code before the transport gets released is better in my opinion.
That may be more manual but it keeps the development team informed as to what their colleagues are doing, and less experienced programmers can learn from more experienced ones. A peer review can involves using the code inspector, just to make sure everyone is using it.
Naturally there is nothing against doing both peer reviews and having the SAP recommended ATC Quality Manager / Demon with a Pitchfork approach, as long as the Quality Manager actually knows something about programming, hopefully all the Quality Manager would have to do is review the exemptions as any real errors would have been picked up by
· The developer doing their own ATC checks on their own objects in development
· Peer Reviews
· The transport system displaying warnings and errors before releasing the transport to test
Nonetheless having a good explanation of false positives in the SAP system itself can only be a good thing, as it stops someone coming along later and trying to correct the “error”.
To Be Continued
To end with the same paragraph as before, in subsequent blogs I will continue to talk about the thought process behind how I chose what topics to include in the book, enriched with some content that was cut from the final version of the book for reasons of space.
Cheersy Cheers
Paul
- SAP Managed Tags:
5 Comments
