> That's my 2ยข, but feel free to try to convince me otherwise :) Ok, I'll give my best ... how about a dollar? ;-)
> I understand that chains like this are common in Rails apps thanks to good > ideas like composable finders (which generally do not violate Demeter), but I > don't think the parallel chains should appear in client code or in specs. > e.g. if this is a controller spec, the model should expose a single method > that wraps this, and if it's the model spec, the spec should just call the > method that wraps the chain with different inputs and and specify the > expected outcomes. I dislike the idea to extract a single line of chained method calls into its own method, just because it is easier to test then. It is not used anywhere else and the method it is in is not very large either (those would be reasons to extract that code in its own method). By the way, it is part of the model. I would agree if it were part of the controller. > Even if I were in favor of the concept, the example above is confusing > because it is a stub that becomes a message expectation. I absolutely agree. I also thought about that when I read my post for a second time. How about: MyModel.should_receive_chain(...) _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
