<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:garamond,new york,times,serif;font-size:12pt">Thanks, Jarkko. Substruct is not my code, so I don't know how OrderHelper got to be so big. I'm not sure I want to refactor its contents into Order just to make it easier to write the examples for my addition, but at least I have that option because the project is open source!<br><br>I'll have a detailed look at your suggestions later today, hopefully. Rails programming is not my day job, unfortunately!<br><br><br>Al<div><div style="font-family: garamond,new york,times,serif; font-size: 12pt;"><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Jarkko Laine <jarkko@jlaine.net><br>To: rspec-users <rspec-users@rubyforge.org><br>Sent: Tuesday, November 20, 2007 12:04:13 AM<br>Subject: Re: [rspec-users]
confirming that a model instance was correctly created from POST params<br><br>
<br>On 20.11.2007, at 8.00, Al Chou wrote:<br>> What I am trying to demonstrate to myself is that the addition of a <br>> boolean "is_business_address" column to the order_addresses table <br>> via a migration allows line 40 of the create_order_from_post method <br>> to set this property when an OrderAddress instance is created. But <br>> my example as shown tells me that assigns[:billing_address] is nil <br>> when I run it. Also, I realize that line 16 of the example isn't <br>> returning the right thing; it should be an AssociationCollection of <br>> OrderAddress. That's where I'm starting to wonder if I'm spending <br>> too much time on something that is probably simple enough that it's <br>> already working but disproportionately hard to write an RSpec <br>> example for (because the existing create_order_from_post method has <br>>
no tests or examples and thus isn't easy to test -- witness the 32 <br>> lines, modulo blank lines, of stubbing just to get the example to <br>> run).<br>><br>> Suggestions on how to write the example, or advice on whether to <br>> continue to try, are requested.<br><br>A couple of points:<br><br>* I have a similar situation with shipping and billing addresses. I <br>solved it by adding attr_accessor :single_address to the customer <br>model. That gives you the option of using "check_box :single_address" <br>in the form for the customer and it will automatically be passed to <br>the model when you update its attributes. I've noticed it cleans up <br>the controller code a lot.<br>* for line 16 in the spec, you need to do something like this:<br><br>order_addresses = []<br>order_addresses.stub!(:create).and_return(order_address) # <br>order_address must be created before
this<br>order_user.stub!( :order_addresses ).and_return( order_addresses )<br><br>* You should put all the stubbing and mocking in a before(:each) <br>block, they don't really belong to the actual spec.<br>* What you have in your helper is basically business domain stuff. <br>Helpers in Rails are meant for streamlining view code. I just <br>refactored some code that does similar things that yours does, and <br>noticed that it fits perfectly in the model. So in your case, you <br>could add e.g. a class method Order.create_with_addresses_and_user <br>(params[:order], params[:order_user], params[:billing_address], params <br>[:shipping_address], params[:order_account]). In that case, all you'd <br>have to spec in the controller is that the class method is called <br>with correct params. All the other spec'ing would go into the model's <br>specs.<br>* Unless your db supports nested transactions (very few do),
there's <br>no point in putting nested transaction blocks in your code.<br>* You can shorten your mocks a bit by defining the stubbed methods <br>already in the mock_model call:<br><br>order_account = mock_model( OrderAccount, :valid? => true,<br> :order_id= => true,<br> :save! => true )<br><br>and so on. Also, once your specs are more than just the one, you <br>start finding patterns there and you can easily refactor the stubbing <br>into spec helpers so that you only need a line or two to create a
<br>comprehensive mock model in your specs.<br><br>HTH,<br>//jarkko<br><br>P.S. in Ruby true and false are normally written in lower case.<br><br>--<br>Jarkko Laine<br><a href="http://jlaine.net" target="_blank">http://jlaine.net</a><br><a href="http://dotherightthing.com" target="_blank">http://dotherightthing.com</a><br><a href="http://www.railsecommerce.com" target="_blank">http://www.railsecommerce.com</a><br><a href="http://odesign.fi" target="_blank">http://odesign.fi</a><br><br><br>_______________________________________________<br>rspec-users mailing list<br><a ymailto="mailto:rspec-users@rubyforge.org" href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/rspec-users" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-users</a></div></div></div></div><br>
<hr size=1>Get easy, one-click access to your favorites.
<a href="http://us.rd.yahoo.com/evt=51443/*http://www.yahoo.com/r/hs"> Make Yahoo! your homepage.</a>
</body></html>