Differences between revisions 1 and 10 (spanning 9 versions)
Revision 1 as of 2005-08-12 17:09:06
Size: 3110
Editor: DanNorth
Comment:
Revision 10 as of 2006-03-21 22:43:43
Size: 2206
Editor: 12
Comment: fixed misspelling of "example"
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
''As an example, when I was first getting to grips with TDD, I was pairing with an experienced agile coach, writing little test methods, then writing the code, and generally feeling good about life. Then I went ahead and wrote some code without a test. When asked why, he answered: "we'll need it in a minute", to which JR, the coach, replied "yes, we might". By using the word "might", he introduced the possibility that we ''might not''. As it turned out, we didn't.'' - DanNorth ''As an example, when I was first getting to grips with TDD, I was pairing with an experienced agile coach, writing little test methods, then writing the code, and generally feeling good about life. Then I went ahead and wrote some code without a test. The coach, JR, asked me why I'd written the code. I answered: "we'll need it in a minute", to which JR replied "yes, we might". By using the word "might", he introduced the possibility that we __might not__. As it turned out, we didn't.'' - DanNorth
Line 5: Line 5:
A coach introducing Test-Driven Development to sceptical (i.e. most) developers invariably runs into the same set of objections. A coach introducing Test-Driven Development to sceptical (i.e. most) developers invariably runs into a familiar set of objections.
Line 7: Line 7:
From programmers:
Why do I need to write tests? That's what testers do.
Writing all these tests slows me down, it's a waste of time.
I'm a good programmer! I don't need to write tests to prove my code works
And from testers:
Why are you getting programmers to write tests? We all know they can't – that's why you need testers.
Are you trying to take our jobs away?
You obviously don't understand testing or you wouldn't be getting programmers to write tests!
This last comment is particularly ironic. In fact, as you will see, the testers take on a central and very important role in Behaviour-Driven Development.
An interesting side-effect of BDD is that it reintroduces the role of the Systems Analyst or Architect, something that has been relegated to the sidelines of agile development (“the architecture will sort itself out – let it evolve”), often with dramatic negative consequences.
Finally, Behaviour-Driven Development scales. It is equally robust on a programme team of 200 as it is on a project with 4 developers, an analyst and a tester. It leverages techniques developed by ThoughtWorks delivering large (multi-million dollar) programmes of work spanning multiple timezones and three figure team sizes.
BDD is not appropriate for all classes of problems. In general the more complex and the more business-critical a software system, the better a fit it will be with BDD. The exceptions to this fit into two categories.
The first are pure “number crunching” systems such as financial modelling applications or analytics engines, where there isn't really any incremental benefit until the whole system is in place.These systems are typified by having an exclusively data-oriented test strategy (matching inputs with outputs). The system has no “behaviour” as such, just a beast of a calculation (or other) engine. It is sometimes possible to deliver such a system incrementally, but this is the exception rather than the norm.
The other category is a Pure Package System. In this case we are simply bolting together existing third-party packages, so the behaviour-driven model doesn't apply.1
BDD can work with embedded systems development, provided you have a sufficiently complete emulator with an appropriate suite of behaviours (test harness) around it.
'''''From programmers:'''''
 - Why do I need to write tests? That's what testers do.

 - Writing all these tests slows me down, it's a waste of time.

 - I'm a good programmer! I don't need to write tests to prove my code works

'''''And from testers:'''''
 - Why are you getting programmers to write tests? We all know they can't – that's why you need testers.

 - Are you trying to take our jobs away?

 - You obviously don't understand testing or you wouldn't be asking programmers to write tests!

This last comment is particularly ironic. In fact, the testers take on a central and very important role in BehaviourDrivenDevelopment.

The behaviour-centric vocabulary helps us to avoid these common misunderstandings and focus on [:BehaviourDrivenDevelopment:BDD] as a design and delivery process.

Concentrating on finding the right words led us to think about the process differently, for example, the fact that the words we use in [:BehaviourDrivenDevelopment:BDD] are very much focussed on the behaviour of the system led us to better understand the very close relationship between the stories we use to specify behaviour and the specifications we implement in [:BehaviourDrivenDevelopment:BDD] in place of tests. It also helped us gain further insight into some of the failure modes we have experienced in [:TestDrivenDevelopment:TDD] projects.

BehaviourDrivenDevelopment grew out of a thought experiment based on NeuroLinguisticProgramming techniques. The idea is that the words you use influence the way you think about something.

As an example, when I was first getting to grips with TDD, I was pairing with an experienced agile coach, writing little test methods, then writing the code, and generally feeling good about life. Then I went ahead and wrote some code without a test. The coach, JR, asked me why I'd written the code. I answered: "we'll need it in a minute", to which JR replied "yes, we might". By using the word "might", he introduced the possibility that we might not. As it turned out, we didn't. - DanNorth

A coach introducing Test-Driven Development to sceptical (i.e. most) developers invariably runs into a familiar set of objections.

From programmers:

  • - Why do I need to write tests? That's what testers do. - Writing all these tests slows me down, it's a waste of time. - I'm a good programmer! I don't need to write tests to prove my code works

And from testers:

  • - Why are you getting programmers to write tests? We all know they can't – that's why you need testers. - Are you trying to take our jobs away? - You obviously don't understand testing or you wouldn't be asking programmers to write tests!

This last comment is particularly ironic. In fact, the testers take on a central and very important role in BehaviourDrivenDevelopment.

The behaviour-centric vocabulary helps us to avoid these common misunderstandings and focus on [:BehaviourDrivenDevelopment:BDD] as a design and delivery process.

Concentrating on finding the right words led us to think about the process differently, for example, the fact that the words we use in [:BehaviourDrivenDevelopment:BDD] are very much focussed on the behaviour of the system led us to better understand the very close relationship between the stories we use to specify behaviour and the specifications we implement in [:BehaviourDrivenDevelopment:BDD] in place of tests. It also helped us gain further insight into some of the failure modes we have experienced in [:TestDrivenDevelopment:TDD] projects.

BDDWiki: GettingTheWordsRight (last edited 2009-05-13 10:41:13 by MarkCrowther)