[TODO] Port views matchers from rspec to Remarkable to provide I18n.

# v3.0.0

[ENHANCEMENT] redirect_to and render_template were ported from rspec-rails to
remarkable to provide I18n. The second was also extended to deal with :with,
:layout and :content_type as options.

render_with_layout, render_without_layout delegate their logic to render_template
so they share the same options.

respond_with_content_type and respond_wity_body delegate their logic to
respond_with matcher, so they also share the same options.

:set_the_flash was also redesign to inherit from :set_session, providing a
consistent API.

[ENHANCEMENT] remarkable_rails now ships with a new feature, called macro stubs.
This allows you to declare just once your mocks and/or expectations, and each
matcher will know how to deal with properly. A TasksController could have your
specs for a destroy action rewritten like this:

  describe :delete => :destroy, :id => 37 do
    expects :find, :on => Task, :with => '37', :returns => proc { mock_task }
    expects :destroy, :on => mock_task

    should_assign_to :task, :with => proc { mock_task }
    should_redirect_to { tasks_url }
  end

This will generate two tests, the first one will assert the assignment of
:task and the second will assert if the action is redirecting to tasks_url.

But before doing the assertions, each macros run the expectations declared and
perform the action automatically. In other words, should assign to macro is
doing:

  it 'should assign to task' do
    Task.should_receive(:find).with('37').and_return(mock_task)
    mock_task.should_receive(:destroy)
    delete :destroy, :id => '37'
    assigns(:task).should == mock_task
  end

On the other hand, should render template is doing something like this:

  it 'should render template show' do
    Task.stub!(:find).and_return(mock_task)
    mock_task.should_receive(:destroy)
    delete :destroy, :id => '37'
    response.should render_template('show')
  end

But how each macro knows if they should perform expectations or stubs? By default,
only should_assign_to macro performs expectations (check macro stubs documentation
to change this behavior).

Finally, you don't need to play with procs all the time. There is a convenience
method called mock_models that generates both class and instance method. So
doing this:

  describe ProjectsController do
    mock_models :project
  end

Is the same as:

  def self.mock_project
    proc { mock_project }
  end

  def mock_project(stubs={})
    @project ||= mock_model(Project, stubs)
  end

For more options, information and configuration, check macro stubs documentation.

# v2.x

[ENHANCMENT] Added assign_to, filter_params, render_with_layout, respond_with
respond_with_content_type, set_session and set_the_flash matchers.