Re: Test first as specification

Phlip wrote:
> hansewetz@xxxxxxxxxxx> wrote in message
>
> > The problem is that this type of view puts severe restrictions on what
> > business people can state as requirements.
>
> That's a problem?

Again, it all boils down to the definition of the term 'requirement'.
You have simply introduced a new definition for the term requirement in
TDD. This is OK and I don't really have a problem with that. However,
it should be clear that your definition of requirement is NOT the same
as the definition that many developers had before TDD was introduced to
the world.

> > 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.
>
> The team does that. The programmers help the business side translate dreams
> into tests, and the programmers teach the business side to create Acceptance
> Tests. This leads to steering the project from where it is, not idle
> speculation where it could be.

OK, I'll rename my BAR to 'dreams'.

> > I would propose to do away with the term 'requirement' when TDD is
> > used.
>
> That's why I always say "specification". As in "testers lead a TDD project
> by collaborating with clients to convert requirements into testable
> specifications."

Hmmm ... I remember having a discussion about 'specification' before.
My understanding in the TDD world is that there is a 1-1 mapping
between specifications and tests. Let me loop back to the beginning of
my previous posting, but change the word 'requirement' to
'specification'.

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: 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)
  • 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. ... > cases the refactoring would not have been as painful as you feared. ...
    (comp.object)
  • Server hardware vendors
    ... I would like some advice regarding server manufacturers and specifications. ... I am starting out as a Small business IT consultant and would like to build ...
    (microsoft.public.windows.server.sbs)