TestFirstDevelopmentOfWebApplicationsWithXML

From SPA Wiki

Jump to: navigation, search

Test-First Development of Web Applications with XML

To paraphrase the audience reaction: why do it? I think we had trouble explaining that there was any benefit from the approach.

That said, useful suggestions for improvements emerged from the discussion. These included:

  1. Use an XML database with XPATH / XQUERY scripting instead of separate XML fragments for each record
  1. Use Eclipse templating facility instead of cutting/pasting to create test scripts in Http'Unit
  1. There may have been a suggestion about a better way to transform our source XML into Web'Test XML - but I forgot to write it down
  1. Our aim of giving business analysts an easily understood forms-based interface to the test specification wasn't really achieved, because Authentic still isn't very intuitive. Result: very few users (none on the business side)
  1. Beware the limitations of Canoo Web'Test

We had barely scratched the surface of Web'Test, because all we were trying to do was check that the right HTTP response codes and headers were returned from HTTP requests. The difficulty begins when you want to describe the actual page content you expect. Html'Unit (on which Canoo Web'Test is based) is actually rather good at this, but Web'Test prevents you from accessing most of this functionality by insisting on using XML tags instead of code for everything.

I suspect that you just have to know how to write tags in the right way to get at the underlying Html'Unit functionality. Certainly Html'Unit seems more straightforward than Http'Unit, paradoxically enough, even for our requirements that involved no HTML generation or parsing at all.

I certainly wouldn't recommend substituting Java (the test scripting language of Html'Unit) with XML (the test scripting language of Web'Test) because the Java is far easier to read and to understand, as well as to write. However, if Web'Test XML could be generated from a human-understandable form of test specification, then we would be getting somewhere.

One unexpected but (with hindsight) predictable benefit of the forms-based approach was that the test spec was unusually consistent and complete. This made creation of the test script very quick and easy. Problems arose later when changes had to be made to the tests - it became increasingly tedious to keep the spec in step with the script. This is where the script generation capability would have come into its own.

Immo Hüneke, Senior Systems Architect, Zuhlke Engineering Ltd 1