Shoulda

Testing RSpec
#1

I just stumbled upon this link this morning where Shoulda makes it easy
to automatically load custom macros. Is there a similar feature in
RSpec?

http://technicalpickles.com/posts/shoulda-can-automatically-load-custom-macros

Andy

#2

We do something similar to this, though we use a convention to set
@klass to the class being spec’d in the top-level example group,
rather than deriving it as they do in that sample.

In view specs we also use a convention to always have a do_render
method available, so that we can bring in similarly shared / generated
examples.

It’s great for speccing two sublcasses which have some common
behaviour, where it feels wrong to spec the (abstract) base class.

#3

Are you willing to provide a simple example?

Andy

Matt W. wrote:

We do something similar to this, though we use a convention to set
@klass to the class being spec’d in the top-level example group,
rather than deriving it as they do in that sample.

In view specs we also use a convention to always have a do_render
method available, so that we can bring in similarly shared / generated
examples.

It’s great for speccing two sublcasses which have some common
behaviour, where it feels wrong to spec the (abstract) base class.

#4

On Tue, Sep 30, 2008 at 8:41 AM, Andy F. [email protected]
wrote:

Are you willing to provide a simple example?

I’m using the same example as the articled you linked to originally as
the base. This way you should be able to clearly see the differences.

http://gist.github.com/13804

Zach

examples.

–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com

#5

Also, a nice thing about RSpec is that when you do describe an actual
object, ie: “describe Foo”, you can determine this by asking the
example group what it’s described type is.

This makes things a lot simpler and cleaner than having to hack away
strings, or guess based on the name of your test.

Zach

On Tue, Sep 30, 2008 at 8:57 AM, Zach D. [email protected]
wrote:

–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com

–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com

#6

On Tue, Sep 30, 2008 at 7:59 AM, Zach D. [email protected]
wrote:

On Tue, Sep 30, 2008 at 8:41 AM, Andy F. [email protected] wrote:

Are you willing to provide a simple example?

I’m using the same example as the articled you linked to originally as
the base. This way you should be able to clearly see the differences.

http://gist.github.com/13804

Here’s a variation on that with a helper for defining macros that I’m
thinking of adding to rspec. Lemme know what you think:

http://gist.github.com/13821

Cheers,
David

#7

David C. wrote:

Here’s a variation on that with a helper for defining macros that I’m
thinking of adding to rspec. Lemme know what you think:

http://gist.github.com/13821

Cheers,
David

+1
I like it. For rspec-rails it would also be nice to be able to say:

define_macros(:for => :controller) do
…
end

define_macros(:for => :models) do
…
end
etc…

Also, instead of yielding within another block you can simply pass in
the given block as an arg:

def define_macros(&macro_block)
Spec::Example::ExampleGroupMethods.extend Module.new(&macro_block)
end

You probably knew this but I thought I would point it out because it
seems that it would give you better performance. (I have not tested that
assumption at all.)

-Ben

#8

On Tue, Sep 30, 2008 at 10:38 AM, Ben M. [email protected] wrote:

This makes things a lot simpler and cleaner than having to hack away

Here’s a variation on that with a helper for defining macros that I’m
I like it. For rspec-rails it would also be nice to be able to say:
Also, instead of yielding within another block you can simply pass in the
given block as an arg:

def define_macros(&macro_block)
Spec::Example::ExampleGroupMethods.extend Module.new(&macro_block)
end

You probably knew this but I thought I would point it out because it seems
that it would give you better performance. (I have not tested that
assumption at all.)

I like David’s suggestion and I also like Ben’s suggestion on top of
it. +1 to both.

–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com

#9

On Tue, Sep 30, 2008 at 10:18 PM, Andy F. [email protected]
wrote:

Here’s a variation on that with a helper for defining macros that I’m
thinking of adding to rspec. Lemme know what you think:

http://gist.github.com/13821

What’s not to like?! Despite the fact that a new RSpec version was just
released, it would be nice to see a new version released right away with
this concept built in so that a RSpec version of Shoulda could start
rolling. :slight_smile:

Not quite sure how we got from discussing an idea to release planning,
but the idea of a shoulda-like library built on this is a good one. If
you’re planning on writing one, no need to wait for this to appear in
rspec. It’s 3 lines of code that you could include in such a library
until such time as it is released w/ RSpec.

Cheers,
David

#10

On Tue, Sep 30, 2008 at 9:38 AM, Ben M. [email protected] wrote:

This makes things a lot simpler and cleaner than having to hack away

Here’s a variation on that with a helper for defining macros that I’m
I like it. For rspec-rails it would also be nice to be able to say:
Also, instead of yielding within another block you can simply pass in the
given block as an arg:

def define_macros(&macro_block)
Spec::Example::ExampleGroupMethods.extend Module.new(&macro_block)
end

Close but not quite. Here are two similar examples that work:

def define_macros(&block)
Spec::Example::ExampleGroupMethods.module_eval(&block)
end

def define_macros(&block)
Spec::Example::ExampleGroupMethods.extend Module.new(&block.call)
end

I think the first is nicer if we’re not too concerned with control or
traceability, but the second, w/ the Module.new on a separate line,
would support maintaining references to the module (if that would be
useful).

Cheers,
David

#11

I was actually teasing… :slight_smile:

As far as writing one… already on it!

David C. wrote:

On Tue, Sep 30, 2008 at 10:18 PM, Andy F. [email protected]
wrote:

Here’s a variation on that with a helper for defining macros that I’m
thinking of adding to rspec. Lemme know what you think:

http://gist.github.com/13821

What’s not to like?! Despite the fact that a new RSpec version was just
released, it would be nice to see a new version released right away with
this concept built in so that a RSpec version of Shoulda could start
rolling. :slight_smile:

Not quite sure how we got from discussing an idea to release planning,
but the idea of a shoulda-like library built on this is a good one. If
you’re planning on writing one, no need to wait for this to appear in
rspec. It’s 3 lines of code that you could include in such a library
until such time as it is released w/ RSpec.

Cheers,
David

#12

What’s not to like?! Despite the fact that a new RSpec version was just
released, it would be nice to see a new version released right away with
this concept built in so that a RSpec version of Shoulda could start
rolling. :slight_smile:

David C. wrote:

On Tue, Sep 30, 2008 at 7:59 AM, Zach D. [email protected]
wrote:

On Tue, Sep 30, 2008 at 8:41 AM, Andy F. [email protected] wrote:

Are you willing to provide a simple example?

I’m using the same example as the articled you linked to originally as
the base. This way you should be able to clearly see the differences.

http://gist.github.com/13804

Here’s a variation on that with a helper for defining macros that I’m
thinking of adding to rspec. Lemme know what you think:

http://gist.github.com/13821

Cheers,
David

#13

I updated the gist posting. All of the macros should be functional now
and have cleaned up describe blocks.

http://gist.github.com/14050

Andy F. wrote:

It is a bit ugly but here is an initial port of the Shoulda ActiveRecord
macros:

http://gist.github.com/14050

I did not try running ALL of the macros, but most of them. Before going
too far with it, I would appreciate some recommendations as to how to
improve the flow. The Shoulda version has a different feel to it since
the assertions cause the code to die early. Whereas the RSpec
conversion I did mostly wrap each should call in its own it block.

Thanks for the help! I learned a lot from this exercise!

Andy

#14

It is a bit ugly but here is an initial port of the Shoulda ActiveRecord
macros:

http://gist.github.com/14050

I did not try running ALL of the macros, but most of them. Before going
too far with it, I would appreciate some recommendations as to how to
improve the flow. The Shoulda version has a different feel to it since
the assertions cause the code to die early. Whereas the RSpec
conversion I did mostly wrap each should call in its own it block.

Thanks for the help! I learned a lot from this exercise!

Andy

David C. wrote:

On Tue, Sep 30, 2008 at 9:38 AM, Ben M. [email protected] wrote:

This makes things a lot simpler and cleaner than having to hack away

Here’s a variation on that with a helper for defining macros that I’m
I like it. For rspec-rails it would also be nice to be able to say:
Also, instead of yielding within another block you can simply pass in the
given block as an arg:

def define_macros(&macro_block)
Spec::Example::ExampleGroupMethods.extend Module.new(&macro_block)
end

Close but not quite. Here are two similar examples that work:

def define_macros(&block)
Spec::Example::ExampleGroupMethods.module_eval(&block)
end

def define_macros(&block)
Spec::Example::ExampleGroupMethods.extend Module.new(&block.call)
end

I think the first is nicer if we’re not too concerned with control or
traceability, but the second, w/ the Module.new on a separate line,
would support maintaining references to the module (if that would be
useful).

Cheers,
David