At the moment I'm trying to become a test driven developer. I started my project some weeks ago and blogged about it. In fact I am still struggling with test driven programming in ABAP and I will write about the difficulties, soon. But writing XML transformations in a test driven way is quite natural for me. Transformations can be tested easily - ususally you don't have to worry about side effects, asynchronous calls, RFCs and so on.
I already blogged about unit tests for XSLT and then I experimented with Simple Transformations. Simple Transformations (or ST programs) are an ABAP proprietary language for coding symmetric XML to ABAP in a streamlike, procedural fashion. I think I was developing Simple Transformations in a test driven way right from the start:
- I take an XML document to deserialize as test case, define ABAP values for the data roots - and write a test short report that uses CALL TRANSFORMATION.
- Then I copy the sample XML document in the editor for transformations and create the ST program by enriching the XML with ST commands like tt:loop and tt:value.
- At the same time I create the data roots in the ABAP data dictionary and I'm completing and testing my ST program.
An Open Source Tool for Testing Deserialization Automatically
Creating ST programs in a test driven way is done really quickly. But one thing is missing: I want to keep the test cases within the SAP system to do regression tests automatically. Therefore I created a tool that allows to keep the XML documents within eCATT data containers together with the content of the data roots.
You can download a SAPlink nugget containing the necessary code from the Open Source community project http://code.google.com/p/axl-project . You have to install the nugget using SAPlink and then do an upload of an eCATT test data container within the ZIP-file using transaction SAAB.
My tool contains a test case as an example which is explained in the rest of this blog entry.
Test Cases as Variantes of an eCATT Test Data Container
So this is how you do it: For each ST program I create an eCATT test data container with the name of the transformation. Then create parameters for the test case. Every test case should contain a default parameter _XML that is a string that contains an XML document to deserialize. For each data root there is an own parameter: ROOT1 and ROOT2 in the example - but of course you can define arbitrary roots unless their name within the transformation is not _XML.
Now I introduce test cases as variants: TESTCASE1 and TESTCASE2. For those varaiants I define parameter values. I leave the values of the ECATTDEFAULT variant initial because this variant is only a master template. The reason is simple: There might be test cases (which correspond to variants) that have initial data roots. But in this case the eCATT API takes the corresponding parameter of the ECATTDEFAULT variant as default, which is unwanted here:
For each test case I define values: An parameter _XML that is the input document for the serialization process:
Then I define values for the ROOT1 and ROOT2 parameter. Those values will be compared with the result of the ST program:
This is an fact the expected result of my ST program if it transforms the XML document from my test case:
<tt:root name="root1"/>
<tt:root name="root2"/>
<tt:template>
<Response>
<tt:cond>
<Error>
<Code tt:value-ref=".root1.code"/>
<Description tt:value-ref=".root1.description"/>
</Error>
</tt:cond>
...
</Response>
</tt:template>
The Test Driver For Test Automatization
My framework has a report ZAXL_ST_UNIT_MAIN that has a name of a transformation as input, searches for eCATT test data container of the same name, take all variants except ECATTDEFAULT and performs the test. My SAPlink nugget contains above transformation so the test can be done with my report ZAXL_ST_UNIT_MAIN:
Summary
I think my "classical" approach for regressions of ST programs is quite natural. Simple Transformations are a very easy to learn. They don't have the complexity of XSLT and modularization is much more easier compared to XSLT because you don't have templates with modes, functions, self defined XPath functions and so on. So a transformation is a testable unit as long as you can guarantee your test cases cover every template of your ST program.
I hope it will other developers of XML transformations help to improve quality of their software. But My pathetic framework still has a lot of weaknesses: It doesn't support regression test for serialization because comparing XML documents is a difficult thing.
Another drawback is the fact that the error message when deserialization fails doesn't contain much information about the error. In my opinion the framework should be able to contain the more information if the ST processor throws an exception and it should show the result of a transformation in case of an error.
I don't know whether I can add those features this year but I would be glad if someone joins my project.
