On Sep 28, 2008, at 5:01 pm, David Chelimsky wrote:
Wow.
OK - here's what I figured out. Talk about insidious bugs! This is
actually quite a bit different from what I thought.
There are two lambdas involved here:
lambda {
1st lambda: expression that should cause the change
}.should change{
2nd lambda: expression that returns the object that should change
}.to(expected value)
The matcher executes the 1st lambda and stores the result as @before.
In your example this is a Rails association proxy for the
Story.unposted collection.
The matcher then executes the 2nd lambda.
The matcher then executes the 1st lambda again and stores the result
as @after. In your example, this is, again, a Rails association proxy
for the Story.unposted collection.
Hey,
Thanks for looking at this so quick! I'm sure I should be paying for
RSpec :)
I think I follow, except shouldn't your references to lambdas 1 and 2
be reversed above?
At this point, @before and @after point to the same object - the same
Rails association proxy!!!!!!
The matcher passes if @before != @after and fails if @before ==
@after. Because they are actually the same association proxy, the
example fails.
Now rspec asks the matcher to print out the reason why it failed,
which does this:
"#{result} should have been changed to [EMAIL PROTECTED], but is now
[EMAIL PROTECTED]"
@to is the expected value []
@after is the association proxy, which proxies to an empty collection.
Now, when the matcher calls @after.inspect, is the first time that the
proxy is actually evaluated!!!!
Does this make sense?
Yes I sees what's going on now.
But... I'm not using Rails, and in fact I'm not even writing a web
app. I'm using DataMapper, but clearly it violates the PoLS like AR.
What I'd give for an ORM that uses plain old Ruby objects!!!
Ashley
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
