[Rspec-devel] New proc.should_increment method

aslak hellesoy aslak.hellesoy at gmail.com
Fri Jul 14 13:41:14 EDT 2006


On 7/14/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 7/13/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > I just added a new little goodie:
> >
> > arr = []
> > lambda { arr << "something" }.should_increment arr, :length
> >
> > See http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5055&group_id=797
> >
> > A little bit on the state side of the fence (as opposed to
> > behavioural), but it's still a nice little feature methinks.
>
> -1
>
> I saw in the page linked above "State based testing isn't ALWAYS bad".
> I agree w/ that statement, but I also think that it's important that
> rspec offers better solutions rather than conveniences.
>

I should have mailed the list before adding this. I had a case for
when it was convenient, and with the lack of a better solution I went
ahead and added it.

I'm all for removing the feature from RSpec - it's easy enough for me
to monkey patch ShouldHelper in my own project to add
should_increment.

> In the case of the rails controller tests, I've been working on an
> acts_as_mock plugin that allows you to mock the class methods as well
> as instance methods, allowing for this (expressed in test/unit for the
> time being - apologies):
>
>   def test_create_should_redirect_to_list_when_successful
>     Story.should_receive(:new).and_return(@story)
>     @story.should_receive(:save).and_return(true)
>
>     post :create
>
>     assert_response :redirect
>     assert_template nil
>   end
>
>   def test_create_should_re_render_new_when_NOT_successful
>     Story.should_receive(:new).and_return(@story)
>     @story.should_receive(:save).and_return(false)
>
>     post :create
>
>     assert_response :success
>     assert_template 'new'
>   end
>
>
> To me, this is the direction we should be moving, rather than making
> it convenient to do things that we want to generally discourage.
>

I agree.

Would it make sense to add your acts_as_mock plugin to RSpec core?

> This also brings up an important, higher level discussion vis a vis
> what features should be going into rspec. I'll get that rolling in a
> separate thread.
>

The protocol should still be what I just violated - email the list and
see what people think. The committers will decide based on input from
others.

I like what you said about avoiding dirty conveniences.

Aslak

> David
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the Rspec-devel mailing list