Re: RE: Test-driven XSLT development?

> 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).
>
>

Not only that, but also all the various ways to count days:

http://en.wikipedia.org/wiki/Day_count_convention

I've had the joy of writing a bond interest calculator...



--
Andrew Welch
http://andrewjwelch.com