SDL, Testing, and the Scripting Debate

I'm really loving the effort I invested in SDL, it's very clean, very useful stuff. I'm beginning to productize Tapestry test framework and I'm targetting SDL, not XML, as the language for the scripts. Background: for Tapestry 3.0, I developed a "mock unit test" suite, more of an integration suite, where I simulate a servlet container around Tapestry pages and components. There's no HTTP involved, but none of the Tapestry objects know that ... they see the Servlet API and, for Tapestry's needs, it works just like the real thing.

Each script consists of a few definitions, and a series of sequential requests. Each request passes up query parameters, and makes assertions about the result of the request: mostly in terms of asserting text in the output (sometimes in the form of regular expressions).

However, the tests are pretty ugly; because a lot of the assertions are looking for HTML, there's lots of CDATA sections. The execution and parsing code is all twisted together and built on top of JDom. Line-precise error reporting came later, so it can be a challenge to find where, inside a test script, a failure occured. In addition, all the code is inside the junit folder, not part of the Tapestry framework itself, so it can only be used by Tapestry itself.

I'm currently starting to rebuild this support for use by Tapestry and for end-user applications. I'm building a better parser, using SDL as the script language, and building tests for the testing framework itself as I go (Who watches the Watchmen? Who tests the Testers?). Lots of work up front, but will easily pay for itself when we start adding more complicated tests for some of the 3.1 features ... I also expect it to run much faster.

Meanwhile, the debate about replacing XML and SDL in HiveMind with scripting rages on. I don't see the advantage to the scripting approaches ... they're all more verbose than the equivalent SDL. It's more code to do the same thing that you'd normally do by referencing builder factories. It won't document as HiveDoc, it raises many issues about multithreading. It adds unwanted dependencies to the HiveMind core framework. No one has made a compelling argument ... certainly not compelling enough for me to spend any time on that when I have other priorities, and so far, nobody else is checking code into the HiveMind CVS. So ... we have a fairly active HiveMind community but I'm still the only developer ... do I like this, or not?