ABAP_to_the_Future

3
ABAP Unit and Test-Driven Development
Quite simply, you can make any change s you want to—radical changes—introduce
new technology, totally refactor (redesign) the innards of the program,
anything at all, and after you change ev en one line of code you can follow the
menu path Test 폷 Unit Test and know—within seconds—if you have broken any
existing functions. This is not to be sneezed at. It is in fact the Holy Grail of programming.
One question that has not come up yet is this: What if someone else comes along
and changes your program by adding a new feature, but accidently breaks something
else and doesn’t bother to run the unit tests, and thus doesn’t realize that
he’s broken something? Clearly, you somehow need to embed the automated
unit tests into the whole change contro l procedure. Conveniently, this leads
nicely to the subject of the next chapter: the ABAP Test Cockpit.
Recommended Reading
왘 Head First Design Patterns (Freeman et al., O’Reilly Media, 2004)
왘 Behavior-Driven Development: http://dannorth.net/introducing-bdd (Dan North)
왘 The Art of Unit Testing: http://artofunittesting.com (Roy Osherove)
왘 Dependency Injection: http://scn.sap.com/community/abap/blog/2013/08/28/
dependency-injection-for-abap (Jack Stewart)
왘 mockA: http://uwekunath.wordpress.com/2013/10/16/mocka-released-a-new-abapmocking-framework
(Uwe Kunath)
174