On Sat, Mar 28, 2009 at 9:49 AM, Brandon Olivares <programmer2...@gmail.com> wrote: > > So, I'm confused. I've been trying to use Cucumber and RSpec, but step > definitions and RSpec examples just seem to be overlapping. What should go > in either one of these?
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. So you need to have bot levels. You specify your overall behavior with Cucumber, then you specify the isolated behaviors of the pieces to make that work, and then you write your code. That's the full-round-trip, complete by-the-RSpec-book BDD answer. 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.) I think the real answer is to try it a few different ways, decide what works within your comfort level *and* leads to good code, and let yourself experiment. And then, if you develop an effective working pattern down the road that you think makes good general sense, share it with the community as one more way of doing things. >8-> -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
