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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
