[xsl] RE: Test-driven XSLT development?

[Norm Birkett <Norm.Birkett@xxxxxxxxx>]

> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@xxxxxxxxx]
...
> I see on Amazon that there are entire books on test-driven software
> development. Is the topic of writing tests and testing code so deep
> that it requires an entire book? If I read one of those books will it
> take my software development skills to a whole new level?

As with most subjects in computer program, the answer to both your questions
is yes and no.

What is covered in books on testing and test-driven development? Inter alia,
* Categories and terminology -- helpful for all; critical for anyone who must
interact with formal test methods and testing professionals. (E.g., what do
you call a test whose purpose is to insure that a change hasn't broken
anything that was already working?)
* Quality management standards -- critical if you must adhere to them (as many
of us in finance and accounting must do, and as lots of programmers must do in
medical systems, power-management, nuclear-plant-management, defense, etc.)
* Implications of all of the above for how you organize your software
development and maintenance workflow -- ditto.
* Implications of all of the above for how you design software.

The last point is the one I find most interesting and practical (speaking as
someone who has to design a fair bit of software annually). Some interfaces
are easy to test, others much harder. For example, in a financial system, you
often need to be able to calculate "accrued interest" on trades (which is the
amount of interest that has accrued on a particular bond, for example, up to a
particular date). If you only have an accrued interest interface that requires
a bond identifier and date, then testing (esp. regression testing--see above)
will be a bear, because now you need to have a bond database hooked up to your
test environment (to look up bond details), and, more tricky still, you need
to make sure that your regression test script includes bond-date combinations
that cover all the code paths (very nasty to maintain). But if you expose a
lower-layer interface that takes some sort of cashflow structure
representation, abstracted from the bond representation, plus a date, now you
can design your test cases more directly in terms of the relevant
considerations ("odd-period end date landing on as-of date," etc. ad
nauseam).

How much of all of that will be relevant to XSL scripts? Depends on what
they're being used for, but my barely-informed sense is that their penetration
into the kinds of problem domains where this stuff is critical is pretty
minimal, outside of some financial systems' messaging interfaces. But that's
just a wild guess.

Norm