Extreme Programming for Web Projects

I l @ ve RuBoard

XML and XSLT open up a wide variety of unit-testing possibilities. [2] With XML you can test that a file is well formed (i.e., that it conforms to the basic rules of XML structure) simply by checking if it can be read by an XML parser without generating an error. As discussed earlier, validating parsers and schema documents can be used for this purpose. Beyond structure validation, test scripts can be written that use an XML parser to examine the contents of a file and ensure that text nodes and attributes contain the appropriate values.

[2] See Chapter 14 for a full discussion of unit testing.

Unit testing can be done on an XML file both before and after its transformation by an XSLT style sheet. Before the XSLT is applied, you can test the raw XML data to ensure that it contains the correct information and is properly structured. After the XSLT is applied, you can test the output to ensure that the transformation succeeded and that the resulting output is properly formatted.

Output Methods

Testing XSLT output is easy if you set the output method of the style sheet to xml. XSLT supports three output methods: xml , html , and text , which you can set with the <xsl:output> element. Even though you are transforming your source XML into HTML, you can set the output to XML, which will basically result in an XHTML document that can be loaded into your XML parser.

Testing Options

Once you have loaded your output XHTML into your XML parser, there are a number of things you can do with it. As a first step you can test that it conforms to the XHTML specification by validating it against one of the XHTML DTDs. (You can download these DTDs from http://www.w3.org/TR/xhtml1/.)

XML versus HTML: Image Tags

One example of the difference in setting your style sheet to XML rather than HTML is a template that contains an image tag. In XML you must have matching opening or closing tags. Thus, a pair of tags with no content (e.g., <x></x> ) can be written with an empty tag notation that uses a slash following the tag name (e.g., <x /> ). An XML parser treats both of these notations as equivalent. An HTML image tag is written as <img src=""> , which violates the XML matching tag rule. In the source code of your XSLT style sheet, you specify an image in the output as <img src="" /> , but if the output method is set to HTML, the XSLT processor converts <img src="" /> to an old-fashioned <img src=""> . If you attempt to load this output document into an XML parser, it will generate an error, but if the output method is set as xml , the result will be a proper XHTML <img src="" /> tag.

You can also check for the existence and structure of various elements on the page by inserting element IDs into your XSLT templates so that the elements can be quickly retrieved and tested . For example, a template that inserts a banner ad at the top of a page can write it as

<img id="banner ad" src=""ad7.gif" width="" height="" onClick="bannerClick()"/>

To verify that the XSL properly inserted the ad, a unit test can be written that uses the parser API to find a node containing the attribute id="banner ad ". The test can check that the height and width attribute values are correct, or it can perform a link check on the image's src attribute to make sure that the image is there.

Another possibility for unit testing is enforcing policies for using Cascading Style Sheets (CSSs). CSSs can (and should) be used with the XHTML output of XSLT style sheets in much the same way they are used with standard HTML Web sites. CSSs and XSLT go well together, with XSLT used to lay out a page and CSSs applied to various page elements by adding class attributes. As long as the XHTML page generated by the XSLT contains a link to a CSS, that CSS will be applied by the browser. In any project using CSSs, sloppy HTML or XSLT designers are often tempted to slip in a little bgcolor attribute here and a <font> tag there rather than define a new CSS class. Now that we are loading our XHTML into an XML parser, we can write unit tests that look for these abominations in an XHTML page and generate errors any time they appear.

XSLTUnit

Up until now we have been discussing ways to perform unit tests on an entire XHTML Web page from a site. A unit test queries the Web server and retrieves a page, with all of its content, and performs test on it. Another approach to unit testing XSLT is for the test function itself to transform some XML code with a style sheet and perform tests on the results. In this way you can write tests that elicit exact results, right down to the text contents of the output. This is the approach taken by XSLTUnit, a generic XSLT unit testing tool, available for download from http://xsltunit.org/.

The currently posted version of XSLTUnit is 0.1. Described by its author as a "proof of concept" at this stage, it shows promise for being developed into a robust and powerful tool.

XSLTUnit supports the writing of unit tests themselves in XSLT. It contains a library of templates that are called by the test style sheet, and it provides two basic testing methods: matching the output against some expected reference XML and XPATH tests.

One advantage of XSLTUnit is that it can test individual templates within a larger style sheet by passing to that style sheet small XML snippets that correspond to a small part of a complete XML Web page. Once these snippets are passed to the XSLT, just the templates that are designed to transform them are invoked, thereby allowing a more targeted unit test.

I l @ ve RuBoard
Related

Категории