Re: Test first as specification

Roger L. Cauvin wrote:
> "Robert C. Martin" <unclebob@xxxxxxxxxxxxxxxx> wrote in message
> news:ckhcf19bde0rk63o3qk8dpbeqjh0v6s4bm@xxxxxxxxxx
> >
> > I don't follow. If a requirement does not have to be
> > verified prior to deployment, then it must not be a true
> > requirement.
> >
> > TDD is a discipline that unambiguously verifies all
> > requirements prior to deployment.
>
> I agree with the thrust of your comments here about TDD. We simply have a
> difference in what we mean by "requirement".


Of course there is confusion between "requirement" and "acceptance
criterion"!

After a few discussions on the group I have come to realize that TDD
sees requirements and tests as different views of the same concept.
>>From their viewpoint there exist a concept, let's call it FOO, which
instances can be expressed either as a test, as a requirement or as
executable code. The purpose of expressing a FOO as a test is to be
able to check that the FOO instance is invariant under the
transformation that produced the executable code. The reason for
expressing a FOO instance as a requirement is to let someone express
how they want the software to behave.

The problem is that this type of view puts severe restrictions on what
business people can state as requirements. Business people usually
don't want to say anything about the software - they want to state
what should happen in the world when the software executes. To satisfy
TDD, the business people will have to reduce their wishes to a few
statements that describe the state of the world at specific points in
time. They have to do this since they know that the rules of TDD state
that it is not allowed to wish for something that cannot be transformed
into an executable test - and executable tests can only check a small
number of discrete states. If they want the software to sound a bell
every hour for the next 100 years, they cannot state this as a
requirement unless they are willing to wait 100 years.

I would propose to do away with the term 'requirement' when TDD is
used. It is redundant since the term 'test' carries an identical
meaning - that is, for TDD developers, not for all others. Or even
better, introduce the concept of a BAR - a BAR describes how the
business people wants the world to behave when the software is
executed. Now, the only thing we need to do is to transform a BAR into
a requirement ... sorry, a test. On the other hand, a BAR is what most
people refer to as a requirement ...

Regards,
Hans Ewetz

.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... TDD replaces long hours debugging with short minutes writing ... > business people, bean counters, managers etc. ... > solving some problem involving money transactions in a bank. ... > describe my high level model to a business person, ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... >>> that TDD is a good thing. ... >business people, bean counters, managers etc. ... >solving some problem involving money transactions in a bank. ... cases the refactoring would not have been as painful as you feared. ...
    (comp.object)
  • Re: TDD doesnt suck
    ... One myth of TDD is "write a test case that fails in such a way that only the ... Write a minimal test for proposed functionality. ... I evaluate foo and get an error (bar not written yet) ...
    (comp.programming)
  • Re: OOP/OOD Philosophy
    ... So it would seem that the 'intentional approximation' is not the design ... tests written in code, or *executable* tests written in UML, I don't ... > the system executes in the manner that the tests specify. ... You strongly reject 'traditional' SE approaches in favour of a TDD ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... In TDD the focal point in development is on automated testing (correct ... business people, bean counters, managers etc. ... solving some problem involving money transactions in a bank. ... describe my high level model to a business person, ...
    (comp.object)