[rspec-users] Evaluating shared example customisation block before shared block

David Chelimsky dchelimsky at gmail.com
Tue Aug 3 20:05:02 EDT 2010


On Aug 3, 2010, at 4:35 PM, Ashley Moran wrote:

> 
> On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote:
> 
>> Pushed:
>> 
>> http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe
>> http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1
> 
> Awesomeness!
> 
> 
>> Please do let me know if this works with what you've got.
> 
> In general, yes, this is a massive improvement!  I've realised some things that never occurred to me before, though.  Maybe you have some thoughts...
> 
> I've put everything on a Gist[1] (which needs a few tweaks here and there, but I think it's a reasonably example).  Notes:
> 
> * DomainLib is my holding module for everything I've extracted out of the project source.  Anything inside that is generic, analogous to eg ActiveRecord (eg Entity <-> AR::Base)
> 
> * I've only pasted the specs, and only the contract-based ones at that (the implementation is not very interesting, nor is the interaction spec).
> 
> * I don't like the word contract any more, at least not here.  It needs a better name, probably something that would fit if you wrote a similar spec for ActiveRecord's has_many.

I actually like contract a lot. Maybe we'll need alias_shared_examples_for_to :)

> Some things I ran into:
> 
> First, I found that you can't use the block variables in local helper methods.  Because Ruby methods aren't closures, I've had to replace methods like:
> 
>  def entity_dot_new_collection_member(*args)
>    entity.send(:"new_#{item_name}", *args)
>  end
> 
> with:
> 
>  define_method :entity_dot_new_collection_member do |*args|
>    entity.send(:"new_#{item_name}", *args)
>  end
> 
> Not a big deal, but it's not as readable as it was before.  (Not that it was exactly large-print Winnie the Pooh to start with, given the abstract nature of the shared examples.)

This is just Ruby. It bugged me for a while too, but mostly because I kept forgetting. Now I'm completely accustomed to it and def and define_method seem quite the same to me.

> Second, you can't refer to `described_class` in the descriptions.  I don't know why I though you'd be able to, but it would be nice if it worked :)  (You can see the place where my failed attempt was, where I left <described_class>.)

This was a mis-alignment between names in the group and its examples (example_group.describes == example.described_class), but is now fixed (you can refer to described_class in both cases): http://github.com/rspec/rspec-core/commit/b236a8d8927da108097fed7982d1450e4701939d

> Finally, I realised something when I added another example.  I should say though, that all this time, I was only using the shared examples with one collection on the entity, and I added another a few minutes ago just for fun, and it just worked... I like :)  But it raised a point about things that are common to all shared examples, and parameters to individual uses.  In my example case, `entity_class` and `entity` are relevant to both of the "collection" shared example groups, but `collection_name`, `item_name`, `class_name` are parameters to the shared examples individually.  
> 
> With the current setup, there's no way to require that a host group provides eg `entity_class`.

shared_examples_for "foo" do
  raise "gotta define entity_class" unless public_instance_methods.map{|m|m.to_s).include?("entity_class")
end

> And also, if it's defined as a `let` in the host, you can't use it in the descriptions in the shared example group (which you couldn't before, of course).

Right - the only thing available to descriptions is going to be the params you pass in.

> So I think this solves 90% of the problems I had before, and is certainly a workable solution to the specs I'm trying to write.  I'd love to hear your thoughts on the rest though.
> 
> 
>> The issue of the evaluation order is still up for grabs, but this now supports params to shared groups in Ruby >= 1.8.7.
> 
> Well, I deliberately didn't check what order you ended up using!  Whatever it is works for me now, although I guess future experiments could change that...

Thanks for all the feedback!

Cheers,
David

> 
> 
> Cheers!
> Ash
> 
> 
> [1] http://gist.github.com/507140
> 
> 
> -- 
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> 
> 
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users



More information about the rspec-users mailing list