-----Original Message-----
From: Costello, Roger L. [mailto:costello(_at_)mitre(_dot_)org]
...
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--