[rspec-users] bad specs better than none?

David Chelimsky dchelimsky at gmail.com
Mon Feb 25 23:13:56 EST 2008

On Mon, Feb 25, 2008 at 8:18 PM, Giles Bowkett <gilesb at gmail.com> 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 :)


>  --
>  Giles Bowkett
>  Blog: http://gilesbowkett.blogspot.com
>  Portfolio: http://www.gilesgoatboy.org
>  Tumblelog: http://giles.tumblr.com
>  Podcast: http://hollywoodgrit.blogspot.com
>  _______________________________________________
>  rspec-users mailing list
>  rspec-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list