Event Information
openSAP – ABAP Unit Testing course – Getting lost in the weeds
Having somehow made it to week 4 of the openSAP course about ABAP Unit Testing it becomes rather apparent that this is way above my still rather rudimentary grasp of ABAP OO – see my earlier post about those particular struggles. Heck, I’m still not really clear about what “Interfaces” are needed for, so – first things first – I’ll need a much better understanding about all things ABAP OO before trying to tackle Unit Testing. So for now, I’m putting my hopes on James E. McDonough’s book “Object-Oriented Design with ABAP” he pointed me to in a comment recently. As of this writing I haven’t yet progressed past page 18 but so far so good – I’m at least not lost yet!
Having said that, it should come as a big surprise if I tell you, that I already skipped most of the exercise in week 3 and haven’t even tried to tackle the ones for week 4 as this is getting too abstract for me – and fast. And it’s not just the ABAP OO stuff itself. There is also way too much new and – to me – rather randomly chosen terminology to take in. Out of “Stub”, “Spy” (why not go for “007”?), “Fake” (which in the age of “Fake news” has quite a negative ring to it!), “Mock”, and “Dummy” only the last one really makes sense to me in the given context.
In addition, it just doesn’t feel quite right to first having to tweak the product code in order to then be able to test some parts of it via unit testing. Having to do that, basically interferes with what was originally specified the code should do. Not to mention that it adds quite some complexitiy especially if it involves having to create local interfaces. It might be a different kettle of fish if you are creating something completely new from scratch where ABAP Unit Testing is one of the defined requirements. But, frankly, I don’t see anybody investing time and money into re-engineering already existing code if it involves efforts like those shown in the lectures.
I did the assignment for week 4 but it already involved quite some guessing. I might still try to complete the course by at least watching the videos for the final two weeks and trying to get some of the answers in the assignments and the final exam right. Not sure, however, if I’ll be able to keep up at all as I’ll be on vacation in Vienna next week where most of my time will be spent by attending the European Geosciences Union General Assembly 2018, obviously something as far removed from anything SAP-, ABAP- or OO-related as it can get (but that’s quite a different topic and story ?)!
Hi Bärbel,
I can see how this week would be difficult to follow, given your background of minimal exposure to ABAP-OO, but: hang in there! There's nothing wrong by needing several rounds of watching the videos, playing with or just looking at the code, etc. I know I needed more than one round in the past (understatement). Not saying I've internalized all of it now :-).
To be fair to the course teachers: all that new terminology was not introduced by SAP, but (many years ago) by the broader development community. They're now more or less part of the general developer vocabulary. IMO the teachers do a decent job trying to explain the terms and their differences.
Thanks for another blog post showing your perspective on the material. I'm sure you're not alone, and as developers we tend to only post about our successes and never mention the hard (and sometimes frustrating) work that precedes those rare moments of enlightenment.
To reiterate: just keep going!
Fred
Thanks for the encouragement, Fred!
Not related to TDD per se, but your question about interfaces inspired me to write this blog https://blogs.sap.com/2018/04/05/using-an-interface-in-oops-for-the-strategy-pattern/ Maybe it will help you understand one use case of interfaces.
In TDD, you use interfaces so that you can (for example) slip in a pretend database class instance for testing, so that during testing you don’t have to write to the actual database. The production application, meanwhile, uses a class with the same interface, that reads and writes to the actual database.
The thing is, that once the application has an instance, it doesn’t care whether the actual class it is using is pretending to access a database or is actually is. So its behaviour is the same whether under test or in production -which is what you want to be able to test the code.
As far as tweaking existing code so that you can write automated unit tests, well, it all comes down to cost. If you’re working for a company that doesn’t care about the total cost of ownership of an application, but just that it gets enhanced and in production as fast as possible (never mind the quality, feel the width), then sure, you can’t do it. If you’re working for someone who has an eye to such things, then you can. If the program changes again and you’ve already got the automated tests written, you’ll immediately benefit. It may even be cheaper to make the tweak and write the unit tests (and then the enhancement for the application) for this particular enhancement than changing the code and testing afterwards.
I've just sat through the first few presentations and you have my sympathies. I think the issue is that they show the solution to the problem without clearly explaining the problem. For me it wasn't clear what the changes they show were intended to fix
Concerning
In addition, it just doesn’t feel quite right to first having to tweak the product code in order to then be able to test some parts of it via unit testing. Having to do that, basically interferes with what was originally specified the code should do. Not to mention that it adds quite some complexitiy especially if it involves having to create local interfaces
The reason it's not wrong and it's not interfering, is that many of the actions are very low risk in that they don't change the logic, they just refactor the code base to add usefulness. In this case, better for automated testing.
Promoting a local variable to an attribute won't affect production code outside of the method you're changing
Moving the instantiation to the constructor, or a new method likewise won't affect production code outside of the method you're changing.
Adding an optional parameter that's only ever called from your test methods won't interfere with production code. (What would be nice, is if you could label such a parameter "test" so that it can only be called from a test method - maybe you can, I haven't got that far yet. It would certainly make the change almost zero risk).
Adding an injection method like wise won't affect production code.
Since the local interface, if you create one, is only ever used by the test methods, it won't interfere with production code. The complexity only lies with testing. The production code doesn't care.
I think your concerns here are in fact highlighting one of the good features of OO programming. You can make changes to the code without affecting other parts far more safely. What you're perceiving as "not quite right" is in fact what OO is good at - you can make the code ever more useful and robust by careful refactoring.
Ah forget it. Just read Paul’s blog. https://blogs.sap.com/2018/04/05/open-sap-course-unit-testing-week-four-test-isolation/
Thanks for the link to Paul Hardy's blog post, Matt! It definitely helped me to better understand this unit testing stuff in general and this week's material in particular.
Cheers
Bärbel
Just to add my voice to Paul and Matthew, stick with it.
I’m waiting for the feedback part at the end of week 6 to give my input directly over there, because I also feel the course is excellent in content but not well structured for someone unfamiliar with the topic. The end goal is definitely not clear.
Do what you can, and at the end of the course go back and review from the beginning.
I'm sticking around out of principle at this point. So far I haven't done too bad on the tests (even though some guessing was involved for me too) and expect to get at least a passing grade and some sort of certificate of completion to pin on my cubicle wall. 🙂
I really wish though the course was simply shorter. 4 weeks is already long enough. 6 weeks and I'm already losing interest and focus. Plus longer run increase the risk of scheduling conflicts. E.g. you're going to an event, I had some days off last week, etc. Life interferes.
The whole week about pair programming was not needed at all IMHO and the rest could've been easily compressed.
Have fun at the event and I'm looking forward to reading your next blog!