Re: [Gnu-arch-users] more on the merge-fest

[Mark Thomas]

On Tue, 25 Nov 2003 address@hidden wrote:

> I may misunderstand the point here since I dont know the context, but this
> seems a bit strange to me.
> All the docu for java test suites tell it the other way around; if there
> is a bug or a change in behavior you define the way it should work by
> programming the test suite to do what you expect the API to do.
> If the testsuite breaks (it will) then you fix the sources to make the
> test suite pass.

This style of unit testing is not a panacea.  It encourages "coding to the
test suite" where you just write code so that it passes (unless you have a
perfect test suite, which you won't, there can still be some cases that
you miss.  The worst case scenario is where in writing for a buggy test
suite, you actually break the code).

The "best" way is for two different people to write the code and the test
suite simultaneously and independently from each other (from a previously
agreed requirements specification), and run them against each other.  If
it breaks, then either one could be wrong and you have to go from there.
If it doesn't break, then you might possibly have implemented the
requirements spec properly (though that could still be buggy ;)

In the absence of this level of redundancy, writing the code and the test
suite in either order will be "good enough for government work."  The
reason most textbooks suggest writing the tests first is because we all
know that once the code is written and seems to work, who can be bothered
to write the tests?

Regards,

  Mark Thomas.
-- 
|| Mark Thomas
|| efaref.net
||
|| Blood flows down one leg and up the other.