James Kanze wrote:
> On Sep 5, 10:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
>> But they (well written, test first unit tests) do bridge the gap between
>> a client's requirements (or some formal specification) and the code.
>> As such, they provide an interpretation of those requirements. The
>> interpretation should be validated by a set of customer acceptance tests.
>
> They are an implementation of part of the specification. But
> you can't write them until you have the specification: a precise
> English (or other human) language document as to what the code
> is to do.

Which when provided by customers (those who pay my bills) are at a level
understandable by the customer, not precise technical language.

> And there are more than a few cases that they simply
> cannot cover, and for the most part, they are both more verbose
> than a requirement specification should be, and fail to say a
> lot of things that are essential in a requirement specification.
>
Such as?

I'm not being difficult, just commenting based on a development process
I have been following for a number of years.

>
>> That is where unit and more importantly customer acceptance test
>> frameworks come in. They provide the required vocabulary to enable
>> developers and customers/test engineers to to specifying the assertions
>> in a meaningful way.
>
> If the customer can read and write unit tests, he's perfectly
> capable of implementing the code himself, and doesn't need you.

You didn't read what I wrote "and more importantly customer acceptance
test frameworks". Most of my customers can, with a bit of help, use
something like FIT for developing *acceptance* tests, not unit tests.

--
Ian Collins.