What's a proper way of writing request specs in RSpec?

6
votes

tl;dr: Jump to the last paragraph

Recently I've been trying to use RSpec's request specs to do some more targeted testing.

This is how my testing mostly looks:

  • general cucumber feature specification, i.e. user goes to a post with comment, upvotes on a comment and the author gets points
  • model specs for when the model actually has some functinality, i.e. User#upvote(comment)
  • controller specs where I stub most of the things and just try to make sure the code goes the way I expect
  • view specs for when there is something complex in the view, such as rendering a upvote link only when the user didn't already upvote, and these are stubbed as well

The problem is when I have some specific scenario which causes a bug and everything seems to work in the model/view layer where I am unable to reproduce it.

That forces me to write an integration test, which I can also do in cucumber. The problem arises once I am able to actually reproduce it, and I need to figure out why is it happening. This usually means playing around in tests, changing different things and seeing what happens.

For example create a comment that is owned by the user who is trying to upvote, try to vote with an expired session etc. However these are really huge pain to write in Cucumber, because of the need to write a scenario and then specify each step.

At this point, I prefer to write a request spec, because it is more low level and allows me to directly do stuff. The problem is, that I'm not really sure how to properly write a request spec, or what are the rules.

A simple example here is:

visit login_path
fill_in "Username", :with => user.username
fill_in "Password", :with => user.password
click_button "Log in"

vs

post sessions_path(:username => user.username, :password => user.password)

or even something more low level like

session[:user_id] = user.id # this actually doesn't work, but the idea is there

Both of these examples achieve the same thing, they'll log a user in. I know that the answer to which one to pick is based on what I need to test, but that doesn't answer the correct, conventional way to do this.

I've been trying to find something about request specs, but they're not really described anywhere. The RSpec book doesn't cover them, the RSpec documentation doesn't say anything either.

What is a correct way to write request specs? When should I use capybara and when just the Rails' #get and #post methods instead of clicking buttons and visiting paths?

2
ruby-on-railsrubyruby-on-rails-3rspecrspec2
Integration (aka request) specs are supposed to mimic user's behavior, and so I usually stick with Capybara's helpers (visit/fill_in, click etc...). But well, it's not that frozen and rules are made to be broken (on purpose). See relishapp.com/rspec/rspec-rails/docs/request-specs/request-spec . Notice I don't use Cucumber. – apneadiving
I use the standard get/post request testing when I am testing a behavior of the controller. For example when I say something should just appear for an admin. In my spec I authenticate an admin and verify that option is in the body. I do not do clicking/visiting. The only time I ever use clicking and visiting stuff is when there is some logic in the view like jquery. Otherwise the view code should be trivial. So in your upvoting your own comment example I would build a user using a helper, build a comment for that user then post a request to say /upvote and say "it should return 403" – Michael Papile
I use model/view/controller tests to test the code, capybara (or cucumber and ..) to test the user interaction (or the integration of all components). I could use the request specs to test the routing / controller integration), and I think that's what it's meant to be for, but in my opinion it's not needed. The request tests you need if you have no integration tests. e.g if you write an api only thing with only machine interaction, then you could go with solution II, otherwise I would go with solution capybara. – Beffa

2 Answers

3
votes

For requests spec I believe the convention is to stick to testing user behaviour and interface interactions, which would mean loading the page, filling in the form etc. A website user cant set the session or interact with variables directly so neither should your request specs.

I've often been tempted to skip page loads and form interactions by posting or setting variables in request specs (for speeds sake, especially heavy ajax specs) but it really does break the purpose of a request spec.

As the comments mentioned, you should test the specific controller / view behaviour in the other spec types.

0
votes

Sermon first....

I think the natural progression of YOU the test writer goes:

  1. Controller
  2. Model
  3. Requests
  4. a mix of Request, Controller and Model specs.

I know that I started looking at the controller first, cause it was easier to grasp.

You then get into Model specs, for non-happy path things...

Then you realize rspec doesn't actually render the view, so you are starting to see dumb errors in Airbrake, so you say, shoot... I need to test the views, and the workflow. Hence Request specs.

Lastly, you get older and realize, all 3 are important and should be used sparingly, but accordingly. I'm just at step 4 now... too many request specs, and you are slogging 5 mins for the whole suite on a medium sized app. sucks.

To answer your question:

I test workflow and views i need to be "seen" (with page.should or any tricky JS (jquery ui selectors for instance) with capybara in a request spec.

If i just need to make sure the controller variables are instantiated or to do something quick with a post for a non-happy path , out of workflow thing... I use the controller. E.g., POST to IPN Controller in paypal...

You'd be surprised how much this covers. This leaves you to test the models for all the whacked out stuff you need for total all the edge cases.

Honestly though, I'd say use Fixtures and Test Unit for integration tests... still like them better, faster... stronger... etc.