Subject: [xsl] RE: Test-driven XSLT development?
From: Norm Birkett <Norm.Birkett@xxxxxxxxx>
Date: Thu, 29 Mar 2012 14:22:52 +0000
> -----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