RSpec Scaffold Controller, understanding the defaults being given

Question

I'm working through an rspec tutorial (peepcode tutorial). I generated some scaffold and I was hoping someone can help explain how the describe could be re-written to read a bit clearer for newbie.

describe "POST create" do

    describe "with valid params" do
      it "assigns a newly created weather as @weather" do
        Weather.stub(:new).with({'these' => 'params'}) { mock_weather(:save => true) }
        post :create, :weather => {'these' => 'params'}
        assigns(:weather).should be(mock_weather)
      end

end

This line of code is what I'm trying to understand is this one

Weather.stub(:new).with({'these' => 'params'}) { mock_weather(:save => true) }

I have never seen a method being put inside braces. What does this actually mean?

{ mock_weather(:save => true) }

Answer 1

As for your first question about "how to make it a bit clearer", we could begin by not using mocks.

A mock object is useful when you can not depend on a predictable behavior of a secondary object, an object that is not important but must be present in your test case. Typical examples of the usage of mock objects are database queries, network usage, file i/o. You don't want your tests to fail because your computer lost network connection, or a database is not available.

The generated code that you got from the rails g scaffold is not optimal. The generated code was generated in a way that will make all tests pass, and for that it uses mock objects. I don't know why they do that, I think a better default would be failing tests so that you actually need to do something to make them pass.

I would delete the generated mocks and do something like the following:

#spec/controllers/weather_controller_spec.rb
describe "POST create" do
  describe "with valid params" do
    it "assigns a newly created weather as @weather" do
      post :create, :weather => {'location' => 'ORD', 'temp'=>'35', 'sample_time'=>'2011-02-04T20:00-0500'}
      assigns(:weather).should be_valid
    end

    it "should redirect you to the weather show page" do
      post :create, :weather => {'location' => 'ORD', 'temp'=>'35', 'sample_time'=>'2011-02-04T20:00-0500'}
      response.should redirect_to(weather_path(assigns[:weather]))
    end
  end

  describe "without valid params" do
    it "should notify that a location is required" do
      post :create, :weather => {'temp'=>'35', 'sample_time'=>'2011-02-04T20:00-0500'}
      flash[:notice].should == 'Location is required.'
      assigns(:weather).should_not be_valid
    end

    it "should notify that a temperature is required" do
      post :create, :weather => {'location' => 'ORD', 'sample_time'=>'2011-02-04T20:00-0500'}
      flash[:notice].should == 'A temperature is required.'
      assigns(:weather).should_not be_valid
    end

    it "should notify that a sample time is required" do
      post :create, :weather => {'location' => 'ORD', 'temp'=>'35'}
      flash[:notice].should == 'A sample time is required.'
      assigns(:weather).should_not be_valid
    end
  end
end

Notice that we are not using mock objects, and so the code is reduced to making the POST call with some parameters and verifying that object is valid. Since will have to write the validation rules in your model file, and you are not using a mock object, you can be sure that an actual validation is going on.

With the auto generated mock files you don't have to do anything at all and the tests will continue to pass forever. That is a bad idea, and bad practice.

Also notice that you should write more tests that exercise the cases where there are invalid or missing parameters. And again, by doing assigns(:weather).should_not be_valid you are verifying that your validations are doing their job.

Writing the dictionary of parameters every time you call post :create is repetitive, fragile and ugly. You should study how to use fixtures. For example, with Factory Girl

#spec/factories.rb
Factory.define :weather_valid do |f|
  f.location "ORD"
  f.temp "35"
  f.sample_time "2011-02-04T20:00-0500"
end


#spec/controllers/weather_controller_spec.rb
describe "POST create" do
  describe "with valid params" do
    it "assigns a newly created weather as @weather" do
      post :create, :weather => Factory.build(:weather_valid).attributes
      assigns(:weather).should be_valid
    end

    it "should redirect you to the weather show page" do
      post :create, :weather => Factory.build(:weather_valid).attributes
      response.should redirect_to(weather_path(assigns[:weather]))
    end
  end
...

That gives you reusable and more readable code.

Answer 2

That statement means:

Stub the new method on the class Weather with the parameters 'these'=>'params' and return the value of the expression mock_weather(:save => true)

A similar and perhaps clearer way to write this would be:

Weather.stub(:new).with({'these'=>'params'}).and_return(mock_weather(:save => true))

The syntax {<some code>} creates a code block which is executed when the stub is called.

The return values of the two forms .and_return() and {} are slightly different; in the first case it is determined when the stub is defined, in the second case it is determined when the message is received. They are generally interchangeable -- but sometimes not.

EDIT

I feel this answer is misleading about mocks and deserves a response:

As for your first question about "how to make it a bit clearer", we could begin by not using mocks. A mock object is useful when you can not depend on a predictable behavior of a secondary object, an object that is not important but must be present in your test case. Typical examples of the usage of mock objects are database queries, network usage, file i/o. You don't want your tests to fail because your computer lost network connection, or a database is not available.

True, mocks can eliminate dependencies on external resources, but that is not their only purpose. The real value of mocks is that they allow you to write tests for code that doesn’t exist yet. In Rails for example, you might decide to start by writing the view specs first.

describe "posts/show.html.erb" do
  it "displays the author name" do
    assign(:post,mock('post',:author=>"Mark Twain"))
    render
    rendered.should contain("written by Mark Twain")
  end
end

This spec doesn’t require the existence of a database, a controller, or a model. All it does is assert that the view needs to render a string and verify that it gets rendered --which is all that a Rails view is supposed to be concerned with. The only dependencies are the existence of the template file and the instance variable @post, which is handled by the assign statement. It doesn't even care what @post is, only that it responds to :author.

The generated code that you got from the rails g scaffold is not optimal. The generated code was generated in a way that will make all tests pass, and for that it uses mock objects. I don't know why they do that, I think a better default would be failing tests so that you actually need to do something to make them pass.

The whole idea of a scaffold is to save time by generating code that works for the usual use cases. Wouldn’t you want the generated tests to actually work too?

Of course by using scaffolding you are doing an end run around the BDD/TDD “test first” paradigm, but presumably you’ve accepted the tradeoffs involved, or you wouldn’t be using the scaffolds in the first place.

As to "why use mock objects", they allow the controller spec to be decoupled from the model and the database. So yes it is "optimal" once you know the reasoning.

With the auto generated mock files you don't have to do anything at all and the tests will continue to pass forever. That is a bad idea, and bad practice.

They will only pass as long as you don’t break the subject code. So they have value in regression testing to ensure that you are not introducing new code or refactoring in a way that causes the code to no longer meet the specs.

Since will have to write the validation rules in your model file, and you are not using a mock object, you can be sure that an actual validation is going on.

This kind of coupling is actually undesirable in a Rails controller spec. The controller should know as little as possible about the model, so the controller specs only need to define what happens when validation passes (or fails) -- and the mock provided by the scaffold does exactly that. If you need to test whether a model instance is valid for a given set of parameters, do that in the model specs.