I promised myself I'd write one blog in SDN this break and this is it. The last few years have been exciting as a developer and as a technical consultant. I really haven't had time to post anything on SDN this year and hopefully to his would be an interesting last-minute-of-the-year insight to a developer or development manager thinking of automated in-code testing.
As technical consultants we often get caught up in the technologies we use, and this break I've been lucky enough to have the chance to look at some of the Microsoft Build sessions precursor to the Windows 8 release. A lot of my searches in this area were around shopping for tablets (Yes - I'm one of the Microsoft faithful waiting for the January release of the Surface Pro). But this time, I was building up on a complementary skills when I got caught up with the testing methodologies being espoused in the latest Visual Studio release. Some of the things being covered in the tool were : Exploratory testing, UI Testing, Test Coverage and Unit testing. The last one "UNIT TESTING" is of interest. ABAP Unit Test classes has been around for a while but a robust practical deployment is still few and far between.
I would highly recommend the first quarter of the discussion to any ABAP developer - particularly those who's familiar and experienced with OO. The rest of discussion is comprehensible but is more of an interesting contrast exercise with SAP for me.
They discussed "Stubs" "Shims" and "Emulators" that support unit test in Visual Studio. For me, it's a nice presentation to contrast the the state-of-the-art in self-proving code between MS and SAP. This is of particular interest as coded unit tests is only starting to gain ground in ABAP development practices to date whereas the methodology is arguable quite embedded in other ecosystems.
In a recent project, I covered a topic of the use of Interfaces to enable Dependency Injection so that our classes can fully support ABAP Unit Test classes. I was curious to see what the Windows 8/Build event had on whole subject of testing and one of the sessions was the one above.
In Visual Studio - "Stubs" allow a predefined behavior returned for an object that the developer has control of (owned or a custom code within a team). In the ABAP landscape, a similar approach, can be done through a good class architecture and Unit test classes. Testing methods can injects a "fake" implementation of a dependent interface with a pre-defined response. This is done so as to control the parameters of test runtime and make it independent of transient data (ie. A unit test should be re-runnable at any time).
"Shims" is interesting. It's the Microsoft reaction to situations where code is dependent on legacy libraries that the developer does not control and that library has a dependency on Resource Calls. This situation makes it unsuitable for automated unit test code. Shims dynamically change object behavior at test runtime such that the development environment can catch the object and give it a predefined result. In a very simple case - imagine you're creating a Z application using a standard class that has a read_po method. The read_po method use BAPI_PO_READ. If "Shims" is implemented in ABAP - it would allow a the unit test class for the application to dynamicaly define the result of the BAPI_PO_READ at test runtime.
( In my SAP Santa's Wishlist --> I can see how this can be implemented in ABAP core. We already have watchpoints in runtime. Since the tests in ABAP behave the similar normal runtime code. Dynamic method / function result redefinition at test-runtime is theoretically not an expensive exercise in ABAP. )
"Emulators" on the other hand are for testing components with dependencies on complex components. If there's an application you're dependent on and it has not yet been completed or is too complex to use in an ABAP Unit test (The example used in Windows is Sharepoint), faking the infrastructure (ie. emulating it so that it returns pre-defined results) can be useful in unit testing. The MS-ALM Tools team has "done the heavy lifting" and created some pre-defined "stubs" for Sharepoint. I can see similar examples in ABAP in dependencies in Cross-Instance applications - APO, CRM, BI etc.
But this is not a blog to argue the merits of a unit test in ABAP, nor is it a blog on an approach on how to create a Policy on unit-testability. It is simply an observation that the wider development landscape is along the same lines, but has far more practice in doing so. MS and the general Software development industry seem to be developing sophisticated ways to test and prove code. As evidenced by the tools and the amount of code in this session, this is fairly advanced in the Windows environment and there's a basis to expect this can become the same in SAP.
( On a slightly different note --> Another one in my SAP Santa Wishlist : One of the other tools I found great was the UI test tool. The tool allowed an exploratory test to be covered in a development environment that captures application state and the steps to get there. It also allowed the tester to log a bug against it right in the runtime environment and can feed into a management of development task lists. )
PS. Have half a dozen paragraphs on Blog 2 "Case Study - Real world example of ABAP Unit Test" about our usage of ABAP Unit tests and where it was useful and how it saved time in regression. From there another blog about thoughts on how to incorporate ABAP Unit Policies in Development Standards. Given my track record on logging in using this id... that may be next year... about December :smile: .
HAPPY NEW YEAR!
