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!
I’ll have a detailed look at your suggestions later today, hopefully.
Rails programming is not my day job, unfortunately!
Al
----- Original Message ----
From: Jarkko L. [email protected]
To: rspec-users [email protected]
Sent: Tuesday, November 20, 2007 12:04:13 AM
Subject: Re: [rspec-users] confirming that a model instance was
correctly created from POST params
On 20.11.2007, at 8.00, Al Chou wrote:
example for (because the existing create_order_from_post method has
no tests or examples and thus isn’t easy to test – witness the 32
lines, modulo blank lines, of stubbing just to get the example to
run).Suggestions on how to write the example, or advice on whether to
continue to try, are requested.
A couple of points:
- I have a similar situation with shipping and billing addresses. I
solved it by adding attr_accessor :single_address to the customer
model. That gives you the option of using “check_box :single_address”
in the form for the customer and it will automatically be passed to
the model when you update its attributes. I’ve noticed it cleans up
the controller code a lot. - for line 16 in the spec, you need to do something like this:
order_addresses = []
order_addresses.stub!(:create).and_return(order_address) #
order_address must be created before this
order_user.stub!( :order_addresses ).and_return( order_addresses )
- You should put all the stubbing and mocking in a before(:each)
block, they don’t really belong to the actual spec. - What you have in your helper is basically business domain stuff.
Helpers in Rails are meant for streamlining view code. I just
refactored some code that does similar things that yours does, and
noticed that it fits perfectly in the model. So in your case, you
could add e.g. a class method Order.create_with_addresses_and_user
(params[:order], params[:order_user], params[:billing_address], params
[:shipping_address], params[:order_account]). In that case, all you’d
have to spec in the controller is that the class method is called
with correct params. All the other spec’ing would go into the model’s
specs. - Unless your db supports nested transactions (very few do), there’s
no point in putting nested transaction blocks in your code. - You can shorten your mocks a bit by defining the stubbed methods
already in the mock_model call:
order_account = mock_model( OrderAccount, :valid? => true,
:order_id= => true,
:save! => true )
and so on. Also, once your specs are more than just the one, you
start finding patterns there and you can easily refactor the stubbing
into spec helpers so that you only need a line or two to create a
comprehensive mock model in your specs.
HTH,
//jarkko
P.S. in Ruby true and false are normally written in lower case.
–
Jarkko L.
http://www.railsecommerce.com
http://odesign.fi
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs