Test Driven Development is a relatively popular methodology nowadays and I think XML tools can play crucial aspect in better testing. Testing frameworks are more than capable of using and testing XML based applications, but just in case you have ever had trouble, here are a few tips.
XSLT makes for an excellent transformation tool for massaging XML data. This means it also can be a helpful tool to reduce large XML data sets to something manageable, whether it is XML or not. For example, here is a simple XSLT stylesheet that will return content on errors checking an Atom Feed:
<xsl:template match="atom:entry">
<xsl:if test="not(atom:title)">
<!-- output similar to "3. No Title" -->
<xsl:value-of select="position(.)" />. No Title
</xsl:if>
</xsl:template>
This is exceptionally simple, but hopefully it makes the point. In the example, you’ll also notice that the output was not contained in a XML Element. Sometimes it is easier to just parse a simple text file line by line, so this might be that situation. Likewise, having a designated set of test elements could be helpful (think reports transformed to HTML). With that said, the goal here is not to create some enormous test framework in XML and XSLT. The real goal is to use a great tool for transforming XML to something you can use easily.
I wouldn’t necessarily suggest trying to validate the content of an element or do complex string parsing. XSLT 1.0 isn’t really the easiest language for string parsing or complex math with out a little help. You can always add your own extension functions to help out, but hopefully keeping things simple by massaging the data gets you 80% of the way. The idea here is make things palatable to your own tastes.
On a side note, I think XSLT is important to consider one part of your toolkit. I’ve seem many people disregard using XSLT for small processing of XML documents because of the fear it would be slow. I’ve also heard smart folks say, "premature optimization is the root of all evil", so it is possible immediate aversion to using XSLT is unwarranted. This is especially true when you consider tests, which often times are forced to be suboptimal in favor of atomicity, do not need to be fast.
If you are only validating elements are present in an XML document XPath is another great option that usually can be used directly. Here is an example using Amara:
import amara, unittest
from mylib.namespaces import COMMON_PREFIXES
class TestXMLService(unittest.TestCase):
def setUp(self):
self.req = MockRequestLib()
def test_get_suitable_atom_entry(self):
xml = self.req.get('/tests/atom/data3.atom')
doc = amara.parse(xml, prefixes=COMMON_PREFIXES)
self.assert_(doc.xml_xpath(u'/a:entry/a:title)[1])
This has a good deal extra code involved, but hopefully it makes the concept clear. This is actually very similar to what Rails has in terms of is tag asserting mechanism. The benefit of this is that you have the power of your XPath library, meaning things like complicated XPath involving namespaces, predicates, etc. all are supported. For example, the Rails tag assertions are very powerful for HTML, but if you need something more complicated you might run into problems, at which point a more robust XPath implementation can be a huge asset.
Hopefully, this gives an option outside the traditional XML Schema and DTD based validations. I like XML, but I hate XML Schema and DTDs. RELAX NG is slightly better option, but when you just want to make sure some value is present, the above methods can be a simpler solution. The essence of the above suggestions come from Schematron, an excellent validation tool that is as simple as knowing XPath. Schematron in fact has been implemented using XSLT, so adding it to your existing test framework should be relatively simple.
There are times when XML seems to present a subtle problem within the world of object oriented languages. It’s not a hard problem on a technical level. Working with XML is relatively simple with many examples and resources. Things get hard when you don’t have good tools to help you along the way. The XML landscape is very mature at this point with many great libraries. Test Driven Development should not be restricted to your programming language of choice when XML has more than enough tools to seamlessly integrate testing your XML along side your models, views, controllers and integrations.


Good read.
I can attest to the utility in both Schematron and TDD. One of the problems I've run into with TDD is the issue of "how many unit tests is enough"; by using an approach that favours quantity over quality (lots of lttle assertions being more beneficial than a larger unit test, especially when you build on shifting sands), Schematron allows you to start out with a core set of assertions, and build on them.
>>> This is especially true when you consider tests, which often times are forced to be suboptimal in favor of atomicity, do not need to be fast.
Exactly.
I wrote a small app a while back to allow testing through XSLT (and XPath and XQuery, XML Schema etc)
http://xchecker.sf.net/
It was useful at the time to allow XPath 2.0 in XSD 1.0 with the smallest possible change to the validation code (you just use the XCheckerSchemaFactory as the SchemaFactory).
You can augment an XSD with XPath 2.0, or you can just use XPath 2.0, or any combination really.
I wrote it because Schematron disappointed me because all that it was, at heart, was an XSLT 1.0 transform. I kept hearing lots about it, but it turned out to be just a spec and couple of transforms, which rightly or wrongly I couldn't quite belive.
Either way, both are likely to be redundant when XSD 1.1 comes along: XSD 1.0 with the annoyances fixed plus assertions.
@ piers
My biggest issue with TDD has been the test frameworks lacking decent ways of testing HTTP for RESTful services. I end up writing my own scripts and using existing tools such as the APE (in the case of AtomPub).
@ Andrew Welch
xchecker looks really cool. I tend to stay away from Java, but it looks so slick I'm going to have to dust of my JVM :) Thanks for the link.
I totally agree with this article and plan to play with Schematron in the nearest future.
One remark is that the text "add your own *extension* functions" provided with the link to FXSL is misleading. FXSL consists of functions all written in 100% pure XSLT.
According to the XSLT 2.0 spec
(http://www.w3.org/TR/xslt20/#dt-extension-function):
"Definition: An extension function is a function that is available for use within an XPath expression, other than a core function defined in [Functions and Operators], an additional function defined in this XSLT specification, a constructor function named after an atomic type, or a stylesheet function defined using an xsl:function declaration.]."
All FXSL functions are "a stylesheet function defined using an xsl:function declaration" and according to the XSLT 2.0 spec definition are not "extension functions".
Cheers,
Dimitre Novatchev
@ Dimitre
Thanks for the clarification. As part of my goal is to point out your excellent library, I would hate to give folks the wrong impression.
I moved the FXSL link and also went ahead and added a link to the 4Suite server XSLT extension functions. While they are not the most obvious help in testing, it makes it clear that assuming you are comfortable adding functions to your XSLT processor (which really is easy) adding extra semi-custom functionality for the purposes of tests or otherwise can make XSLT that much better a tool.
Also, thanks for creating such a great library. I'm usually using Python for my XSLT work, but since you mentioned FXSL is implemented in XSLT, I will be taking a look at adding it to my XSLTemplates library.
Maybe XQuery is a good alternative for XSLT !
With XQuery you can use XPath functions.
In fact in our project we have made a QUnit module (just like JUnit) to test our XML/Query based application
declare function ut:testAtomEntry(entry as atom:entry) {
return if (empty(entry/Title)) then "No title" else ()
};
@ Roger
That looks pretty slick! I hope you will consider releasing it at some point as well. I've stuck to XSLT 1.0 simply because of its availability, but I think you've gotten me interested in a close look at Saxon and all it offers.