Data-wise context combination for controller speccing

[Costa_Shapiro]

Hello,

I’ve been thinking of how to express my idea in code, but since I’ve
never
been involved in RSpec development, I’d better have some feedback here
first.
The feature suggestion below applies to any controller-like code under
spec,
i.e. a stateless module producing output or just altering its data store
(it
doesn’t necessarily have to be a C of the MVC, but I suppose merb/rails
developers will particularly appreciate it).

Here is a skimmed sample to illustrate the pain:

describe BookController do

  context "registering a book" do

    specify "from a new author on a new subject" do
      auth = mock(:name => 'John D.')
      Author.should_receive(:find_

by_name).and_return(nil)
Author.should_receive(:new).and_return(auth)
auth.should_receive(:save).and_return(true)

      subj = mock(:short => 'Mockery')
      Subject.should_receive(:find_by_short).and_return(nil)
      Subject.should_receive(:new).and_return(subj)
      subj.should_receive(:save).and_return(true)

      title = 'Specs on Steroids'

      book = mock
      Book.should_receive(:new).and_return(book)
      book.should_receive(:save).and_return(true)

      post :register :author => auth.name, :title => title, :subject 

=>
subj.short
response.should be_success
end

    specify "from a known author on a new subject" do
      auth = mock(:name => 'Joe Dohn')
      Author.should_receive(:find_by_name).and_return(auth)

      subj = mock(:short => 'Mockery')
      Subject.should_receive(:find_by_short).and_return(nil)
      Subject.should_receive(:new).and_return(subj)
      subj.should_receive(:save).and_return(true)

      title = 'Specs on Steroids II'

      book = mock
      Book.should_receive(:new).and_return(book)
      book.should_receive(:save).and_return(true)

      post :register :author => auth.name, :title => title, :subject 

=>
subj.short
response.should be_success
end

    specify "from a known author on a known subject" do
      auth = mock(:name => 'Joe Dohn')
      Author.should_receive(:find_by_name).and_return(auth)

      subj = mock(:short => 'Forgery')
      Subject.should_receive(:find_by_short).and_return(subj)

      #...
    end

    specify "from a new author on a known subject" do
      #...
    end
  end
end

And this is what I have in mind for doing exactly the same job:

describe BookController do

  context "registering a book" do

    before :any, "from a new author", :author do
      @auth = mock(:name => 'John D.')
      Author.should_receive(:find_by_name).and_return(nil)
      Author.should_receive(:new).and_return(@auth)
      @auth.should_receive(:save).and_return(true)
    end

    before :any, "from a known author", :author do
      @auth = mock(:name => 'Joe Dohn')
      Author.should_receive(:find_by_name).and_return(@auth)
    end

    before :any, "on a new subject", :subject do
      @subj = mock(:short => 'Mockery')
      Subject.should_receive(:find_by_short).and_return(nil)
      Subject.should_receive(:new).and_return(@subj)
      @subj.should_receive(:save).and_return(true)
    end

    before :any, "on a known subject", :subject do
        @subj = mock(:name => 'Joe Dohn')
        Subject.should_receive(:find_by_name).and_return(@subj)
    end

    it "should succeed", :with => [:author, :subject] do
      title = 'Specs on Steroids X'

      post :register :author => @auth.name, :title => title, 

:subject =>
@subj.short
response.should be_success
end
end
end

A run of such specs will effectively multiply the tests — automatically
—
choosing before and after blocks as specified.
I’m sorry, I haven’t thought the DSL through, but I hope the main idea
can
be seen: contexts do not have to be hierarchical.
In my opinion, adding some sort of context selection+combination
capabilities (AOP-style) will contribute greatly to the expressiveness
of
the spec language.

Thank you for your attention,
Costa.

[Costa_Shapiro]

On Jul 17, 2010, at 1:18 PM, Costa Shapiro wrote:

      subj.should_receive(:save).and_return(true)


      Author.should_receive(:find_by_name).and_return(auth)
  end
      @auth = mock(:name => 'John D.')
    before :any, "on a new subject", :subject do

I’m sorry, I haven’t thought the DSL through, but I hope the main idea can be seen: contexts do not have to be hierarchical.
In my opinion, adding some sort of context selection+combination capabilities (AOP-style) will contribute greatly to the expressiveness of the spec language.

I think the idea of mixing/matching sub-contexts is very interesting,
but it definitely needs from fleshing out. It would have to be easy to
read/understand in the spec file as well as the output.

Also, this only works if every combination should behave the same way. I
think we’d need a means of saying “given these combinations of data,
expect these outcomes”.

Anybody else have thoughts on this?

Cheers,
David

[Costa_Shapiro]

On 18 Jul 2010, at 00:10, David C. wrote:

      Subject.should_receive(:find_by_short).and_return(nil)
      response.should be_success

    specify "from a known author on a known subject" do
      #...

    end
        Subject.should_receive(:find_by_name).and_return(@subj)

A run of such specs will effectively multiply the tests — automatically — choosing before and after blocks as specified.
I’m sorry, I haven’t thought the DSL through, but I hope the main idea can be seen: contexts do not have to be hierarchical.
In my opinion, adding some sort of context selection+combination capabilities (AOP-style) will contribute greatly to the expressiveness of the spec language.

I think the idea of mixing/matching sub-contexts is very interesting, but it definitely needs from fleshing out. It would have to be easy to read/understand in the spec file as well as the output.

Also, this only works if every combination should behave the same way. I think we’d need a means of saying “given these combinations of data, expect these outcomes”.

Anybody else have thoughts on this?

It’s a nice idea.

I’m not sure whether I’d use it though. I think this idea comes from the
desire to write specs that are complete, which I can perfectly
understand but I don’t think I subscribe to anymore. I prefer to really
craft the examples so there’s ‘just enough’ tests but no more than that.
I’d be worried this might offer a temptation to think less about why
you’re writing each example, and I’d be worried how that would help me
to do TDD.

It should be possible to do something like this using macros now, right?
Can I suggest that the OP has a go at refactoring his code using macros
and we can see how it looks?

[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

cheers,
Matt

http://blog.mattwynne.net
+44(0)7974 430184

[Costa_Shapiro]

On Jul 19, 2010, at 3:58 AM, Matt W. wrote:

Here is a skimmed sample to illustrate the pain:
auth.should_receive(:save).and_return(true)
book.should_receive(:save).and_return(true)
Subject.should_receive(:find_by_short).and_return(nil)
response.should be_success
end
describe BookController do
before :any, “from a known author”, :author do

    end

Anybody else have thoughts on this?

It’s a nice idea.

I’m not sure whether I’d use it though. I think this idea comes from the desire to write specs that are complete, which I can perfectly understand but I don’t think I subscribe to anymore. I prefer to really craft the examples so there’s ‘just enough’ tests but no more than that. I’d be worried this might offer a temptation to think less about why you’re writing each example, and I’d be worried how that would help me to do TDD.

Agreed this would be a potential pitfall of this approach. I’m also not
convinced this is the right tool for this sort of thing. Seems like
something best expressed in a table:

data do
author do
new { … }
known { … }
end

subject do
new { … }
known { … }
end

outcome do
success { … }
end
end

scenarios <<-SCENARIOS
| author | subject | outcome |
| new | new | success |
| known | new | success |
| new | known | success |
| known | known | success |
SCENARIOS

Something like this might work, but maybe it’s better suited for
Cucumber, or FIT.

[Costa_Shapiro]

On 19 Jul 2010, at 11:38, Wincent C. wrote:

Here is a skimmed sample to illustrate the pain:
auth.should_receive(:save).and_return(true)
book.should_receive(:save).and_return(true)
Subject.should_receive(:find_by_short).and_return(nil)
response.should be_success
end
describe BookController do
before :any, “from a known author”, :author do

  end

And when the alarm bells start to ring, before I think about changing my testing framework to make things easier, I look at the code under test to see if it could be changed to be more testable.

[:foo, :bar, :baz].do |thing|
describe “#{thing} dimensions” do
it ‘has length’ do
thing.to_s.length.should > 0
end
end
end

That’s the kind of thing I meant by macro, yes. Is that a
well-understood use of the word?

---

rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

cheers,
Matt

http://blog.mattwynne.net
+44(0)7974 430184

[Costa_Shapiro]

El 19/07/2010, a las 10:58, Matt W.
escribió:

     Subject.should_receive(:new).and_return(subj)
   end


     @auth = mock(:name => 'Joe Dohn')
   before :any, "on a known subject", :subject do
 end

Anybody else have thoughts on this?

It’s a nice idea.

I’m not sure whether I’d use it though. I think this idea comes from the desire to write specs that are complete, which I can perfectly understand but I don’t think I subscribe to anymore. I prefer to really craft the examples so there’s ‘just enough’ tests but no more than that. I’d be worried this might offer a temptation to think less about why you’re writing each example, and I’d be worried how that would help me to do TDD.

It should be possible to do something like this using macros now, right? Can I suggest that the OP has a go at refactoring his code using macros and we can see how it looks?

I know that the posted code may be a contrived toy example for the
purposes of illustration, but when I see a spec like that alarm bells
start to ring. So much mocking, so many assertions in each example block
etc. And it’s not at all clear what the pertinent behavior is that you
want to test here, because each example looks exactly like a one-to-one
rewrite of the original implementation that uses mocks instead of real
objects.

And when the alarm bells start to ring, before I think about changing my
testing framework to make things easier, I look at the code under test
to see if it could be changed to be more testable.

So we basically have a controller action that accepts three parameters
(author, title, and subject), and it has a conditional code path for two
of those:

if thing.exists
great
else
create it
end

And in your spec you’re wanting to test for all the different
permutations of new author/existing author and new subject/existing
subject.

First thing you could do to eliminate a lot of mocking is use something
like “find_or_create_by_name” and “find_or_create_by_short”. Then you
only have to mock three calls (one for each parameter) and forget about
the permutations entirely.

This is an example of pushing logic down into the model in order to make
controllers simpler and more testable. If “find_or_create_by_*” doesn’t
do what you need it to, then create a model method which does.

You could go even further and create a “register” method on your Book
class which accepted the three parameters of author, title, and subject,
and did everything which you are currently doing in your controller in
the model layer instead. Then your controller spec becomes ridiculously
simple, can be tested with a single mock, and the rest of the logic now
resides in a model, which is easily testable.

So whether or not the example was a toy example, the need for the any
automatic permutation and spec generation in RSpec has disappeared.
Let’s imagine, however, that the need was still there. Would adding this
kind of code to RSpec itself be a good idea?

I don’t necessarily think so. Matt says you can probably do this right
now by using macros. I don’t actually know what he means by that, but I
do know that there are cases where I sometimes want a bunch of nearly
identical specs, and I generate them in code using enumeration or some
other means; ie. dumb example:

[:foo, :bar, :baz].do |thing|
describe “#{thing} dimensions” do
it ‘has length’ do
thing.to_s.length.should > 0
end
end
end

So like I said, if your tests are painful, I think the first port of
call should be to look at how the code under test could be change. Good
code isn’t just code that works. It’s also code that is readable,
maintainable, any among many other things, testable. Adding support to
RSpec to make it easier to test bad code doesn’t seem the right thing to
do.

Maybe you have another example that could illustrate how what you
propose would be useful, but right now I don’t really see the need for
this kind of thing.

Cheers,
Wincent

[Costa_Shapiro]

El 19/07/2010, a las 16:20, Phillip K.
escribió:

Glad to see I’m not the only one that does this.

Yeah, I think it’s a legitimate technique, as long as you don’t get too
carried away with it.

I use it, for example, for some code quality specs:

Wincent::SOURCE_FILES.each do |file|
describe file do
it ‘contains no trailing whitespace’ do
file.should_not have_trailing_whitespace
end

  it 'contains no tabs' do
    file.should_not contain_tabs
  end

  it 'has a newline at the end' do
    file.should have_newline_at_end_of_file
  end
end

end

Cheers,
Wincent

[Costa_Shapiro]

Thank you very much for your valuable feedback.

First, the example is a toy example of course, while the idea of
mixing-matching contexts is not. Note that it would be a totally
backward-compatible enhancement to rspec, and that a developer would
still
be in full control of what gets mixed-matched.

Then, the subject might been confusing (not to mention the unsuccessful
suggested syntax), as the idea is not necessarily coupled with data
permutations.
I accept the criticism about over-mocking, and even more than that, I
find
mocking AR extremely tedious, that’s why I’ve initially thought of
coming up
with something like GitHub - costa/rspec-orm: RSpec plugin for better life with DataMapper, ActiveRecord, etc (there will be a
separate mail on that, please don’t comment it here just yet).

I hope I’ll bring some sort of POC – which will be working for me at
least
– soon. Any comments or suggestions are more than welcome.

Cheers,
Costa.

[Costa_Shapiro]

On 2010-07-19 5:38 AM, Wincent C. wrote:

Here is a skimmed sample to illustrate the pain:
auth.should_receive(:save).and_return(true)
book.should_receive(:save).and_return(true)
Subject.should_receive(:find_by_short).and_return(nil)
response.should be_success
end
describe BookController do
before :any, “from a known author”, :author do

    end

Anybody else have thoughts on this?

This is an example of pushing logic down into the model in order to make controllers simpler and more testable. If “find_or_create_by_*” doesn’t do what you need it to, then create a model method which does.
thing.to_s.length.should> 0
end
end
end

Glad to see I’m not the only one that does this.

Peace,
Phillip