XSL Unit Testing


As I’ve explained before, I’ve been on a quest trying to unit test the world’s most complicated XSL stylesheet. On yesterday’s topic I mentioned a little trick that I use to let errors jump off the screen and bite me in the trousers. I even posted a little code snippet to show how I was doing it. What you probably didn’t see was how ugly the code snippet was or how it was located in the completely worst place. I had the code in another unit test designed for testing an object to XML converter tha also happens to be part of my project. “What good is it doing there?”

I’m glad you asked! Immediately after I copied and pasted the snippet into yesterday’s topic I saw the ugliness. I said to myself, “I can’t use that code in my current unit test even if I wanted to.” Then I decided to move it into my custom ExtendedXMLTestCase class. (Astute readers will note how utterly stoopid that name is and also how it reflects more terrible design. What I really need but have not yet moved to develop is an ExtendedXMLAssert. I know that sounds just as stoopid but consider who you’re dealing with.) By move it, I mean that the original code is still in place but has given birth to an identical twin living in another IntelliJ Idea module. I get lazy sometimes and I know all of these mistakes will come back to bite me. Moving along, I noticed immediately after keying the “Ctrl+V” sequence how dumb the code was. It looked like this:


    public void assertXMLEqualWithDetailedDiff(String expectedXML, String actual)
            throws SAXException, IOException, ParserConfigurationException
    {
        Diff diff = new Diff(expectedXML, actual);
        try
        {
            assertTrue(new DetailedDiff(diff).toString(), diff.identical());
        }
        catch(AssertionFailedError e)
        {
            assertEquals(e.getMessage(), expectedXML, actual);
        }
    }


Notice my stoopidity as I trap an AssertionFailedError in a clumsy attempt to throw it as an AssertionFailedError. Note how I completely use exceptions as conditional flow logic. Also pay attention as birds fly by and crap in my hair while I proudly present the code as a “good idea” on my dumb weblog that nobody ever reads. It takes pure genius to be this retarded. Here’s the revised code:


    public void assertXMLEqualWithDetailedDiff(String message, String expectedXML, String actual)
            throws SAXException, IOException, ParserConfigurationException
    {
        Diff diff = new Diff(expectedXML, actual);
        if(! diff.identical())
        {
            String msg = (EMPTY_STRING.equals(message)) ? EMPTY_STRING :message + "\n";
            assertEquals(msg + new DetailedDiff(diff).toString(), 
                    expectedXML, actual);
        }
    }


Ahh, now that’s a little better right? The logic is in a reuseable class. Exceptions are no longer re-thrown as themselves. Conditional flow is handled by conditional operators, and birds no longer experience spontaneous diarrhea as they fly overhead. Truth be told the code still stinks. It just stinks much better now.

More about unit testing

I got a tip from a cool cat named Bill on the ranch today. It was the best dern’ rootin’ tootin’ feedback I got inna fort night! Bill tol’ me I could use the javax.xml.validation package to validate muh generated stuff. Whiles I was saddlin’ up tuh tell’em thanx and all I figured I’d write about it here. This is good stuff to know. Good fer you greenhorns as well as you sheriffs, and bartender folks cuz the dang JVM grows each release and yuh never know what they fit in there next. By the way, do we really want a doggone database in a future JVM? I guess there’s pros and cons to everything but isn’t a DB s’posed to be a separate product? Next thing they’ll be stuffin’ a darn copy of OpenOffice in the JVM, just in case.

Excuse me, I got caught up in that ranch talk and completely derailed from the topic. I’m going to be trying Bill’s tip on validating my FO and if it works I might rope that into my ExtendedXMLTestCase class too. It’d be nice to have a method like assertFOIsValid() without having to remember all of the specifics about setting up the factory, schema instance, and all. Speaking of which, the other part of Bill’s big idea (that sounds like the name of a great movie or book) was to use Google. It’s amazing how often I forget how to use that program. He instructed me how to enter “xml fo dtd” into the little text box thingy that sits under the colorful letters and then how to click enter to go to next page. Once I did that I saw all kinds of results for FO validation. Hats off to Bill. Now if I can just get my streamed XML formatted with line breaks and indentation I would be on a roll. Break me off somethin’…

(During the author’s search for the hippest sounding slang sign-off your patience is requested. Understanding that the author has been far removed from “the streets” and coolness is not a more prominent virtue, you can expect to get whack terminology like “Holla”, “Break me off”, and the more ridiculous sounding “Hit me with the hee”.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s