"David Chelimsky" <[EMAIL PROTECTED]> writes: > On Thu, Oct 30, 2008 at 5:20 AM, Matt Wynne <[EMAIL PROTECTED]> wrote: >> On 27 Oct 2008, at 16:35, Pat Maddox wrote: >> >>> Matt Wynne <[EMAIL PROTECTED]> writes: >>> >>>> Pat - are you going solo too? >>> >>> Nope, I'm trying to teach RSpec/BDD to an organization that currently >>> doesn't use it and has 0% test coverage. It's interesting, to say the >>> least. They're good devs, but even so, the effects of not writing tests >>> first (or even at all) are painfully evident when trying to get the >>> codebase under test, and especially to change stuff. Really puts your >>> "working effectively with legacy code" chops to work :) >> >> :D >> >> This reminds me of an argument I was going to make for consistently writing >> specs as you go, even for apparently very simple controllers. As the >> controller gets more and more complex, it's hard to know when you've crossed >> the line into something that needs specs, and when you realise it, it's >> usually too late. > > I'd agree with this (in spite of my previous comments), and add to it. > > One of the benefits of writing examples is that they actually help to > expose things that are growing complex. If it's hard to test, it's > probably hard to change. > > Aslak made a good point earlier this thread with "don't write specs > just cuz," but perhaps this fact is sufficient "cuz" to motivate. > > WDYT?
eh I dunno. I mean, I completely agree that hard-to-write tests often expose bad code. But there isn't any gray area when it comes to designing Rails controllers, in my opinion. I see an action that's more than five lines long and I know it's wrong. I don't need to write examples to tell me that. That said, when teaching someone I suppose it would make sense to use examples to illustrate that, at least until they develop an aesthetic appreciation as finely tuned as my own :P Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
