A Framework for XSLT Unit Tests
In one of my TDD Experiment Part 2: Testethics of XSLT I began to experiment to develop XSLT programs in a test driven way. I realized that with some conventions a general solution is possible:
- A unit test is as well as test data are stored in an XSLT program in a certain namespace.
- If we apply the XSLT template with itself as a input the test is performed.
- We can standardize the result of the test case.
For those templates I developed some tools so that regression tests are possible. You can find this small tool together with a sample transformation containing a test case within the nugget.
A Schematron Implementation
Schematron is an XML Schema Language that allows to code assertions using XPath-terms in a special language. This is a very powerful technique that allows you perform validation that go beyond the possibilities of XML Schema. In fact those techniques will be integrated in XML Schema 1.1.
Unfortunately there are only a few validators that support Schematron but fortunately there is a free XSLT implementation by Schematron inventor Rick Jelliffe from Academia Sinica Computing Center, Taiwan. This XSL transformation transforms a schema to another XSLT program that performs the validation. The framework I wrote can help you to keep control about the schematron schemas by storing them in an eCATT container together with meta information like a description, a test case and the name for the XSL transformation to be generated.
I fact I'll have to introduce exception handling by replacing assertions with exceptions and make the whole generation process much more robust.
Some General Thoughts about Open Source in ABAP
In my opinion Open Source development in ABAP has following problems:
- We can't guarantee naming conflicts with customer development in Z-namespace.
- If partners develop software in own namespaces they will have to rename Open Source software to their own namespace.
Because of the namespace conflict it will be very risky to build bigger frameworks or even reuse them. In my opinion this problem could be solved:
- Open Source projects in ABAP could be "approved" by SAP and then could be implemented in a special namespace like /SDN/.
- We could establish naming conventions by establishing certain midfixes for an application. Perhaps we could even go further: with help of a web service we could reserve those midfixes and even build up a global TADIR-table that is build up by scanning SAPlink nuggets to avoid naming conflicts.
Without or without an own namespace naming conventions are very important.
From Nuggets to Software Components
I think there are very innovative Open Source projects in ABAP but the critical mass is not reached yet. But if there would be more Open Source projects in ABAP we could start thinking about creating an own software component I want to name SDN_ABA. SDN_ABA is on top of SAP_ABA (and of course SAP_BASIS) and contains stable releases of Open Source software in ABAP and can be downloaded on SDN.
What is a stable release? In my opinion we have to define a set of quality criteria:
- We need a package concept (i.e. naming conventions for packages containing an Open Source application).
- The software contains test cases (verify reports, unit tests) so that we it can be tested without much effort.
- The development objects have to be correct regarding naming conventions (see above).
- It should contain a demo report that shows how to use the framework.
For building a software component we need a consolidation system. I think the most challenging problem will be the dependency to releases of the netweaver application server. I think most developers would love to work on NSP 7.01 but only a few customers are using it already: In fact in every TechEd session I used so far there were guys who are asking the same questions: "My company is using R/3 4.6C - please tell me how to use brand new Netweaver technology in our production system" ;)
I think there are solutions for that problems: SDN_ABAP has the release 7.00 on a high netweaver EHP release. The developers of an Open Source project tell what kind of release they need - say Netweaver EHP1 for example. Every Open Source software that needs a certain Netweaver EHP must be switchable so that users can decide what they need according to the Netweaver EHP release of their systems.