Depot app, Demeter's law and troubles cleanly specing

On Thu, Apr 23, 2009 at 2:19 PM, Fernando P. [email protected]
wrote:

Rails definitely entices you to break Demeter’s law just so often.

Now how to cleanly spec:

@comment = @article.comments.build(params[:comment]) ?

You think that’s bad, I’ve seen many a code that looks like:

project.tasks.map(&:responsible_party).group_by{ … }.map…sort

Mocking and stubbing is starting to get ugly now.


Posted via http://www.ruby-forum.com/.


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users


Zach D.
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)

On Sun, Apr 26, 2009 at 10:20 PM, Dan N. [email protected] wrote:

2009/4/24 Stephen E. [email protected]

Yeah, I’m a smartass.

Well you seem to be on the right lines to me.

Thank you! That means a great deal to me.


Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Fernando P. wrote:

Hi,

Let’s take the example of the depot app. In my controller I set @order.
Then in the view comes the bad stuff:

@order.items.each do |item|
item.product.title
end

Now I’m having problems specing item.product.title. A quick and dirty
fix is to trade a for for an underscore, so I create Item#product_title:

def product_title
product.title
end

The problem is that I have a few models that act the same way, so I
would find myself writing lot’s of these little instance methods, and
the solution looks a bit stupid to me. So how do you handle such issue?

I thought about composed_of, but AWDWR’s examples still break Demeter’s
law and that annoys me.

Thanks in advance

Hi, please try the Law of Demeter gem

Its a DRY way to apply Law of Demeter with demeter gem

http://gemcutter.org/gems/demeter

On Sun, Apr 26, 2009 at 9:20 PM, Dan N. [email protected] wrote:

it “should make a new comment belonging to the article” do

Mocking and stubbing is starting to get ugly now.

it there.

that…well, Rails is probably doing it wrong. Controllers in Rails
are just doing the Wrong Thing. That’s why specing them is so
painful, and why so many of us skip trying.

I’ve struggled with this bit myself, as I suspect many of us who did
TDD before Rails have.

RSpec’s mocking/stubbing framework just got a contribution that allows
you to do this in a controller spec:

Thing.stub_chain(:all, :with_some_scope, :perhaps_another).
and_return([stub_model(Thing)]

This let’s you stub a chain of named scopes, for example, in a rails
controller. Similarly, with models:

member.stub_chain(:addresses, :first, :zip_code)

Admittedly, this can result in an excuse for poor design choices. In
this example, the first address probably has some meaning that could
be exposed through a method like primary_address() or some such. Even
in that case, I think that allowing
member.stub_chain(:primary_address, :zipcode) would be preferable over
adding methods like primary_address_zipcode(). Of course, a little
method_missing magic could solve that as well :slight_smile: I guess it’s good to
have options.

On Thu, Nov 26, 2009 at 9:24 PM, Emerson Macedo
[email protected]wrote:

Now I’m having problems specing item.product.title. A quick and dirty
I thought about composed_of, but AWDWR’s examples still break Demeter’s
law and that annoys me.

Thanks in advance

Hi, please try the Law of Demeter gem

Its a DRY way to apply Law of Demeter with demeter gem

Interesting. There is a plugin still floating around called Demeter’s
Revenge that does a similar thing with associations rather than
attributes.
So, in the demeter gem, you can do this:

@post.author_name # same as @post.author.name

Whereas in demeters_revenge you can do this:

@post.create_author # same as @post.author.create

Be nice if both sets of behaviour were in one gem :slight_smile: