[rspec-users] confirming that a model instance was correctly created from POST params
jarkko at jlaine.net
Tue Nov 20 03:04:13 EST 2007
On 20.11.2007, at 8.00, Al Chou wrote:
> What I am trying to demonstrate to myself is that the addition of a
> boolean "is_business_address" column to the order_addresses table
> via a migration allows line 40 of the create_order_from_post method
> to set this property when an OrderAddress instance is created. But
> my example as shown tells me that assigns[:billing_address] is nil
> when I run it. Also, I realize that line 16 of the example isn't
> returning the right thing; it should be an AssociationCollection of
> OrderAddress. That's where I'm starting to wonder if I'm spending
> too much time on something that is probably simple enough that it's
> already working but disproportionately hard to write an RSpec
> 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
> 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_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
* 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.
P.S. in Ruby true and false are normally written in lower case.
More information about the rspec-users