On Mon, Feb 25, 2008 at 8:18 PM, Giles B. [email protected] wrote:
Hi - I’ve got a bunch of people using specs at a company. Everybody is
writing specs, but people are not really practicing BDD. As in, the
specs are there, but it doesn’t go, write spec, write code, repeat. I
recently came across 8 failing specs checked into svn; I think the
plan was, I’ll write the design as specs, and then implement the
entire design to match. Obviously that’s not really the way it should
be.
This is a fairly common misconception about what BDD is all about. You
can move in the right direction by making those failing specs pending
so the suite still passes. Then remove pending from one example, watch
it fail, get it to pass, then the next pending example, etc.
I also had to go into specs on a project I’m not working on, and found
an unholy hive of database-accessing specs. It’s disheartening.
Basically, it’s cargo cult development practices - using the “best
practice” without actually understanding it.
This is a really tough problem. The whole motivation for BDD was
“people don’t get TDD, so let’s come up with some new ways to frame it
so people get it.” Now people don’t get the new frame. In that respect
we’ve made things twice as bad.
Should I tell these people to throw away their specs? Should I train
them in the BDD “spec first” cycle? What do you do when you have specs
that are not really that useful? This is mostly Rails stuff; there’s a
lot of controller specs that duplicate model specs instead of stubbing
out the behavior. It’s driving me nuts but I have no idea what the
solution is yet.
If you’re pair programming with these folks, then I’d recommend simply
pushing the pairing sessions in the right direction. Focus on the task
at hand, do it with good discipline, and change anything that’s not
right as you go.
If you’re working from afar, then I’m not sure what to recommend.
There are some people who are going to respond favorably to your
advise and others who will think you’re nuts.
The subject of this thread is “bad specs better than none?” If “bad”
means “wrong” and the examples don’t test what they say they’re
testing, then I’d point that out and ditch them - but probably one at
a time.
If “bad” means that there is poor balance, too much focus on
structure, duplication, etc, then as long as they are really testing
things, I’d leave them and gradually refactor them to a better place.
Or maybe I’d just crack open a beer, grab my guitar and call it a day 
Cheers,
David