[rspec-users] Should change not comparing arrays how I expected

Michael Latta lattam at mac.com
Sun Sep 28 20:56:05 EDT 2008

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  


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
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list