The Challenge of Agile development with XML
What does "Agile Development" mean anyway? Many times during the history of the profession of software development people have become frustrated and disgusted with how so many major projects go bad. Surveying and documenting the wreckage has produced many articles, yet change is slow to come. Robert L. Glass wrote The Universal Elixir and Other Computing Projects which Failed in 1976, and it is still in print. So much of what computer and management science has attempted to do has been trying to find a way to conduct software development to avoid all the pitfalls. From this effort we have gotten languages, management techniques, diagramming languages, etc., but still projects run into trouble.
Many people have felt that there is a basic problem with project management in the "waterfall" style. Essentially this style assumes you can have a stage which documents all the requirements, which neatly flow into a design stage where software architects define a structure, which is then implemented by coders. After verification that the result fits the requirements the product goes out the door.
Now, if this ever worked in the old days it certainly doesn't now! Everything from business requirements and practices to programming language tools and standards are evolving much too rapidly. In recognition of this, many techniques known by a variety of names have arisen. I am just going to lump them all under "agile" developement.
Overview of the Agile Idea
The emphasis in Agile software development is on recognizing that evolving requirements require rapid iteration and constant collaboration between all levels of development. A statement of the "Manifesto for Agile Software Development" at agilemanifest.org contains the following points about what should be valued:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The intent is to create teams which adapt quickly to the inevitable changes in requirements and confirm progress with frequent delivery of working software. Naturally, in early stages, working software may involve many mockups of components to be developed. Furthermore, agile development teams are expected to have frequent complete tests of the components developed so far, preferably as a suite of automated tests which return a detailed list of what is working and what isn't. Idealy this will ensure that individual components are doing what they are supposed to in spite of changing code and requirements.
Unit Testing and Assertions
In software code, "unit testing" is used to verify that a unit of code correctly handles the expected inputs and generates the required outputs. A collection of documented unit tests may form a large part of the formal design document for an entire project as it evolves. Dependencies for one unit on other parts of the project may be faked with mock objects or methods.
Several languages provide for an "assertion" statement which is very useful for unit testing. An assertion defines a logical test which the designer expects to evaluated as true in order for the code to continue executing. For example a statement might assert that a connection to a database must exist at this point in the code.
Typically an assertion, in addition to being executable, forms part of the documentation for a section of code. In Java, assertions are executed at runtime and will halt the program with a custom error message if the assertion fails.
All of the techniques mentioned above depend on modifications—sometimes extensive modifications— to code in some language like Java or C++ in order to promote rapid testing and development. However, the modern world of business processes operating as a complex web of interactions, possibly defined by BPEL, and exchanging XML -ormatted messages presents testing difficulties.
Agile Development with XML and XSLT
While it is easy for unit testing to verify that an input number is in the expected range, legal XML can be quite complex. Superficially different XML tags can be identical as far as the XML infoset is concerned. A search for "agile XML development" finds lots of discussion but not a lot of formal tool development beyond automated testing of XML output versus schema. Schemas and DTDs provide the first line of defense for detecting errors in XML.
An agile development team working on a project using XML should create schema for every document needed early in the project. Naturally, at an early stage many of the XML documents will have to be static "mock" documents standing in for XML to be generated dynamically. Creation of sample XML first will make it easier to create schema since programmers generally find schema rather abstract and tools exist to create draft schema from documents. The essential step of creating example XML and schema should involve as many project participants as possible. One great virtue of such documents is that they can contain human readable text comments as needed to explain all of the reasoning behind the requirements. The XProc XML Pipeline Processing language is ideal for automating tests of XML versus schema.
It seems to me that it is the use of XSLT to modify XML documents that presents the real testing challenge. There is no clear analogy to assertions possible in XSLT, instead developers need a way to formally state what behavior of a XSL transformation is required, which brings us to the XSpec project.
The XSpec Project
XSpec is an open-source project hosted on the Google Project Hosting site. The XSpec project draws on a project in the Ruby language called RSpec which has been in development for several years. However, where RSpec is more general, XSpec is focused on XML tools. XSpec version 0.2, released in March, is provided as a suite of XSLT scripts and Java code. Here is how XSpec is described by the authors in the current download documentation:
XSpec is a Behaviour Driven Development (BDD) framework for XML processing, currently focusing on XSLT and XQuery. It is based on the Spec framework of RSpec, which is a BDD framework for Ruby.
The central idea of Behavior Driven Development requires the developer to write a document which describes the desired behavior of the code. In XSpec, this document, in XML format, describes the desired operation of a XSLT or XQuery script. The XSpec tools convert this document into a new XSLT script which when executed produces a report indicating success or failure. XSpec may turn out to be very useful for developers building XML pipeline applications and the current download contains an example of how to do this.
If you are interested in Agile development with XML, you might want to keep an eye on the XSpec project. However, I found that the current download does not provide enough documentation for a casual user to experiment with the tool. This is still a toolkit undergoing evolution.