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 dat!
e, 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
--~------------------------------------------------------------------
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>
--~--