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

[Ashley Moran]

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.

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.)

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>.)

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`. 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).

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...


Cheers!
Ash


[1] http://gist.github.com/507140


-- 
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran