RSS feed for InstantSpot site orangepips

TDD Backlash

Mon, 03 Mar 2008 19:17:00 GMT

It's been said, "A foolish consistency is the hobgoblin of little minds." And, in my experience TDD can easily slide into this fallacy. So it gladens me to see someone like Cédric Beust, creator of the TestNG unit testing framework, call out the TDD zealots. In addition he also offers some heuristics that I think really capture the essence of how unit testing should be approached.

To wit, I tried introducting unit testing at my workplace and ran into this very problem. But, some background first:

The product I work on is closing in on a decade of development. And stuff that was almost 10 years ago, which is still around and used, has UI, database I/O and business logic all intertwined. Very much a Model 1 architecture. But, before you start ranting about bad design practices and MVC and so forth, know the product works, and makes money. And, it started out in Coldfusion 4. So objects were not an option and Fusebox was nascent at best.

With a codebase like this, you cannot just flip a switch and make it unit testable. Anyone who proclaims changes to said code must be unit testable is not living in reality. It's possible to move in that direction, but if it took you years to create that codebase, don't expect it to take days, weeks or months to get to a unit testable state. These things are intertwined and must be broken apart carefully with planning and coordination with testing.

Programming is fundamentally just as much a social and technical problem. Attempting to impose a command and control structure on programmers == bad idea. But the appeal of implementing a Good Idea as the Only Idea can be overwhelming. This was definitely the case for my environment, where instead of focusing on the notion of having good unit tests, TDD ruled the day and it became you must have unit tests before you code.

This crashed and burned rather quickly as developers pushed back.

Now personally I write unit tests for my code that does not involve database I/O or UI. Where I find the configuring the dependencies, even through injection, outweigh the benefits of unit testing. But as a result, most code that I write separates these aspects out leaving everything else in a unit testable state.

What I do find is that sometimes unit tests makes maintenance easier. But, that sometimes if the change is large, I need to throw out the old tests. Maybe I write new tests or maybe I don't. It just depends on complexity and time. And, for TDD adherents I am sure this is probaby heresay.

XML StAX Processing with Coldfusion

Wed, 28 Mar 2007 15:04:00 GMT

Several problems with Coldfusion XML processing and solution set:

Slow: due to DOM processor (Xerces)
Inconsistent Round-Tripping (i.e. serialization / deserialization) :
1. (un-) escaping characters
2. non-printable characters
3. missing / multiple XML declaration(s)
4. character set problems
5. et al.
Kludgy Tree API yes you can use structure and array functions, just don't like it.

Note, don't see this as a flame on Adobe/Macromedia. The Coldfusion XML implementation uses best available technology at the time and APIs that fit in with the language paradigm. Just have better options now.

Slow Solution

Woodstox: Jim Collins wrote a CFDJ article about using a StAX XML processor with Coldfusion. Unfortunately, as near as I can tell, his open source project to integrate Coldfusion with Woodstox was never released. Testing demonstrates a StAX processor, such as Woodstox, provides very efficient (read: fast) XML processing, and a more intuitive API, than a SAX processor. But still not intuitive enough for me. So enter...

Round-Tripping & API Solutions

XOM provides a very easy to use API that roundtrips XML like a champ. Correct I/O is XOM's middle name. But it doesn't integrate natively with a StAX processor unless you use...

NUX is like a Swiss Army knife for XML. But the purpose of this entry just know it's the glue between XOM and Woodstox (note that NUX includes the XOM jar so you do not need to download it separately).

Code

Download the Woodstox and NUX jars and configure them in your Coldfusion classpath. The examples below build upon each other.

Setup

Creates a XOM Builder object backed by a StAX processor.

inputFactory = createObject("java", "com.ctc.wstx.stax.WstxInputFactory").init()
builder = createObject("java", "nux.xom.io.StaxUtil").createBuilder(local.joInputFactory, javacast("null", "")

XMLParse() Alternative

Returns a XOM Document object. Note: provide XMLString variable.

document = builder.create(XMLString)

XMLSearch() Alternative

Returns a XOM Nodes object (i.e. an iterator of Node objects). Note: provide XQueryString variable.

nodes = createObject("java", "nux.com.xquery.XQueryUtil").xquery(document, XQueryString)

loop from="0" to="#nodes.size() - 1#" index="idx"
element = nodes.get(javacast("int", idx))
attributeValue = element.getAttribute("attributeName").getValue()
attributeText = element.getValue
/loop

ToString() Alternative

Creates a string representation of the XML.

XMLString = document.toXML()