> -----Original Message----- > From: rspec-users-boun...@rubyforge.org [mailto:rspec-users- > boun...@rubyforge.org] On Behalf Of Stephen Eley > Sent: Sunday, March 29, 2009 3:47 PM > To: rspec-users > Subject: Re: [rspec-users] Cucumber step definitions vs. RSpec examples > > This is a subjective judgment call that doesn't have an absolute > 'right' answer. Ask a dozen programmers how they test and you're > likely to get at least three dozen answers. > > I believe the purists would say that the duplication is a feature. > The gist of this point of view is that RSpec's main strength is on the > unit testing level: you want to test that model code works separate > from your controller code, and your controller code separate from your > view code. Then if one fails, you know exactly what class went wrong > and what to fix. > > Cucumber's main strength is on the acceptance or integration level: > you want to make sure it all comes together correctly and creates the > right application behavior, which is very hard to prove with unit > testing alone. But if you _only_ did Cucumber tests, your test to see > if a form exists on a page (to use your example) would be too broad. > If it failed, where do you look first? Is the view broken? The > controller code? Do you even have a model for the view to operate on? > Etc. >
Thank you very much. That is much more understandable. This made me realize I forgot the controller testing for the feature I'm talking about. > My own view... Well, my view is that I've tried that and been driven > nuts by it. Writing specs for controllers and views can take me many > times longer than writing the code. Mocking out the models for > controllers is frustrating and fragile to me, and view specs are just > obvious and tedious. I don't have any _fun_ writing those specs. And > if I'm not having fun, I find myself not motivated to program. > > So I stopped writing those specs, and now I mostly just write model > specs and Cucumber features. It usually doesn't take that long for me > to look at a failing Cucumber test and figure out what went wrong -- > from the failure text, a stacktrace, or sometimes just manually > running the action and eyeballing it. Sometimes, if the controller > action is unusual, I will write a spec for it, but only if my own > instincts tell me it's warranted. (Or if something failed in an odd > way and I want to make sure that doesn't happen again.) > > That's my current answer based on past experience. Next month I might > have a different way of doing things. I'm not going to make the case > here that I'm right and you should never write controller/view specs > for ordinary actions. (If nothing else, doing it a bunch of times -- > and getting some things wrong, then fixing them -- is a great way to > learn how controllers and views really work.) > Yeah, that's what I'm worried about. I wrote probably 5 examples just to test the existence of one field and ensure it had the options I wanted. I'm worried about it taking way too long. But I do like the security provided by extensive unit tests. Thanks, Brandon _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
