On Mon, Feb 25, 2008 at 8:18 PM, Giles Bowkett <[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 > > -- > 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
