I think the difference comes down to whether you are writing specs or
tests. It is good enough for RSpec or Cucumber to fake out AR proxies
if all you are doing is testing something. If it is a spec, then I
believe that having the framework fake out the test is very dangerous,
because a random piece of Ruby code that does the same thing will get
different results than the spec. The bottom line is that AR has bad
behavior in this regard. But, having a spec that pretends it is
otherwise only documents a false view of the world, and other
programmers reading that spec will think that they can count on the
results to be different than they are. The result of the first call
and the second are not different objects, but different contents. It
would be much better if AR was consistent in representing the result
set over time, rather than changing the collection out from under you,
but it does do that.
Just my $0.02, but I really like specs to be treated as specifications
for what SHOULD be happening, not pretending other code is different
than it is.
In this case the argument can be made on whether RSpec is introducing
the change in behavior with its timing of the evaluations and
comparisons, so in this case it is not black and white to me, but I
would lean to more explicit acknowledgment of what AR is rather than
what AR should be. David's suggestion of a constraint that shows the
reader something odd is going on here with the proxies and give them
pause before using the proxy in the same way the RSpec code did
initially.
Michael
On Sep 28, 2008, at 3:09 PM, Ashley Moran wrote:
On Sep 28, 2008, at 7:52 pm, David Chelimsky wrote:
What you're proposing could be resolved with an argument constraint
that's been discussed in some other threads on this list - something
like:
lambda {...}.should change{...}.to(array_consisting_of(...))
I'd prefer this as it lets us keep the single matcher, but allows us
to make it more flexible by adding different constraints. We already
have hash_including. This would expand that sort of capability.
WDYT?
On the basis that my code isn't a Rails app*, but I'd still like
this fix, I vote +1 for "array_consisting_of" (or something).
How about...
lambda {...}.should change{...}.to(collection_equivalent_to(...))
?
Bit long winded but I think it expresses the intent? (Correct me if
not...)
As for change vs change_contents_of, I vote for keeping the one
matcher. I don't think I should be expected to know when an object
that replies to ==([]) is not an array.
Or an H R Giger alien for that matter...
Cheers
Ashley
* Ironically in my attempt to escape Rails, I have, in the same day,
both been bitten by an ORM that behaves like ActiveRecord, and a
different gem that loads ActiveSupport and borks 'require' when I
run my specs. =(
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
