G'day all. Quoting Graham Klyne <[EMAIL PROTECTED]>:
> But I also wonder if this is a sign that the XP approach to test-led > development isn't being followed faithfully. Theoretically (as I > understand XP), the tests *are* the specification. And things that aren't > exposed can't be part of the specification, can they? I don't understand XP this way. The tests are, at best, part of the specification of a module or component. However, the specification of the system as a whole is partially embodied in use cases and, ultimately, the on-site customer. > In practice, I think that there's a slight tension here: tests may embody > the specification, but they also embody some knowledge of the way the code > works, and (I occasionally find) some may be created to provide a finer > granularity of information about how the code is *mis*functioning. Don't you sometimes wish you had a Haskell coverage analysis tool? :-) > Which leads to a question: I've been thinking that the "white box" tests > may be better served by test expressions coded *within* the module > concerned. That's not a bad idea, but there is a problem with this, IMO. When programs get big, the cost of compiling becomes very significant. Assume for a moment that the size of a program grows linearly over its lifetime, that the cost of compiling a program is at least linear in the size of the source code, that recompilations happen regularly and that hardware is not upgraded. (The last assumption is true in many real-world cases; often, build machines are kept "frozen" to minimise the risk of OS/compiler/etc changes introducing changes in the produced software.) A little thought shows that the cost of compiling this program over its lifetime is quadratic in its final size. It's a subtle cost because it's amortised over the lifetime of the software, but reducing the cost of a single compilation pass really does pay off. It follows that introducing code which is immediately thrown away in most cases is probably the wrong thing for many software development tasks. Cheers, Andrew Bromage _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe