On Nov 28, 2010, at 2:06 AM, medihack wrote: >> 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.
We have a fundamental philosophical disagreement here. I see testability as having inherent value, "just because it is easier to test" is a good enough reason to consider a change. > 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). I'm confused about where it _is_ being used? What code actually calls this chain? > 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(...) Need to ponder that. Will follow up with some thoughts. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
