Hey, did you see that error?

I posted some code on my last entry that contained an error. (Is that the right Java term or should I say exception?) Most developers referr to these things as features, so I’ll go with that. The feature was the dang program won’t produce the intended output. It is one of those subtle things that, with proper test driven development practices, should never have existed anywayz. The feature was hidden in the DOMSource instances that I used to do XML diffs. I’m not sure if the feature is a product of my own misunderstanding of XML technology or if it is just the guys from org.custommonkey playing a dirty trick on me. (The joke’s on you son! what with a name like custommonkey… who’s the monkey now! Ha!) At any rate, I learned that you can’t reliably do a diff on to DOMSource instances. Let me be more precise. You cannot accurately diff two DOMSources that have been created using Document instances parsed from the default Xerces XML DOM parser. (Also, I learned that you can’t fire a weapon in Connorsville, Wisconsin if you are of male gender and your female partner is currently experiencing an orgasm.) What a silly restriction to live by. What happens is the diff created from two DOMSource instances always returns identical true. It took me a while (and a spare developer and about 20 minutes of interactive debugging) but I finally resolved to use Document objects directly in the Diff constructor rather than wrapping them in DOMSource constructors.

My revised code is now:

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

    public Document toDocumentNode(String xml) throws SAXException, IOException, ParserConfigurationException{
            Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder()
                            .parse(new ByteArrayInputStream(xml.getBytes()));
            return doc;
        catch(final SAXParseException e)
            Locator locator = new Locator(){
                public int getColumnNumber()
                    return e.getColumnNumber();

                public int getLineNumber()
                    return e.getLineNumber();

                public String getPublicId()
                    return e.getPublicId();

                public String getSystemId()
                    return e.getSystemId();
            SAXParseException saxParseException = new SAXParseException("Could not parse: " + xml, locator);
            throw saxParseException;

Why are you so hung up on comparing XML?

I don’t seem to be able to get a good grasp on the XMLAsserts or something. I mean just when I think I’m done writing XMLAssert convenience methods something else stoopid comes up and bites me. Usually that’s a sign that you’ve done something horribly wrong at a lower level or that one or more of your assumptions about a particular design is flawed. Because I have declared myself the master of all things XML related I will accept niether possibility. Onward and towards inevitable complexity I strive. Do you have a better idea? If so gimme a clue. So far things have been moving slow. I have a stylesheet that writes a stylesheet that writes FO syntax for an engine that writes PDFs and more. I have an object reader that generates SAXEvents to feed my transformation process. I think I’m on the right track.

XSLT Unit Testing?

One other thing. I discovered a unit test framework for XSL. I’m not sure why I never saw it before but a few days ago I started playing with the Juxy project. Juxy is a product that will allow you to invoke templates within a transform and assert the results. It is also a product that will crash on you the first time you use it complaining about a ClassCastException with a w3c Element instance. It’s all good though, the project maintainer is pretty cool. As soon as I got the exception I emailed him and he responded before I could click send. To his (and the project’s) credit I’m not sure the error is in his code. He did send me an updated jar file within 10-20 minutes of my discovering the problem. Thanx Pavel! I wish my telephone company would respond as quickly as you do. Once you get into Juxy (and I can’t get there yet because I’m busy fighting broken XMLAssertions) you find that it’s pretty darn easy to practice TDD on your XSLT stylesheet. I told my boss that moments ago informing him that I don’t need that $1.7K copy of XMLSpy for debugging anymore. (I asked for the $1.7k in cash but he was not responsive so I figure either he’s already bought the license and feels dumb or he heard about my situation earlier and there’s a note with the words “pay to the order of” and the number 1,700 hanging out my mailbox at home.)

That’s about all I have time for now. Maybe tomorrow I’ll have made some good headway on the XSLT coding. Tell me what’s up, people…

One thought on “Hey, did you see that error?

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