[katello-devel] setting mock expectations in a utility method

[Partha Aji]

On 06/30/2011 10:07 AM, Dmitri Dolguikh wrote:
> I came across of this bit of code today:
>
> module OrganizationHelperMethods
>   def new_test_org user=nil
>     Candlepin::Owner.stub!(:create_user).and_return(true)
>     Candlepin::Owner.should_receive(:create).at_least(:once).and_return({})
>     @organization = Organization.create!(:name => 'test_organization', :cp_key => 'test_organization')
>     session[:current_organization_id] = @organization.id
>     return @organization
>   end
>
>
> This a utility method used to create an organization in tests. However, it also sets up a mock expectation Candlepin::Owner.should_receive(:create). There are a few problems with this approach:
>
>  - if the expectation fails every test that calls new_test_org will fail, making it hard[er] to isolate the problem

So should the right approach have been just stubbing that call instead of doing a "should_receive" ?? I think the new_test_org was added because we were copy pasting the org setup code in every test..

>  - this method is used in controller tests, but it tests logic from the model layer, making problem isolation harder (since now a controller test can fail due to a problem with both controller and model logic)

Well this is a generic helper setup method. I can see this being useful both model specs and controllers requiring orgs. Many of the models wont even save if a org is not provided to them.

> When writing tests:
>   - try to only test things that you said you are testing
>   - test things on the logical level of the system under test (test model behaviour if you are testing model classes, and controller behaviour if you are testing controllers; try not to cross this boundary)

What is a good example of tests related to controllers ? As in what can we use as a template ? So for example if its a create product controller test, will my test 
1) Stub the request parameters
2) Call the action
3) Ensure a product object with that id gets created ?

or is it merely checking that the right action is called ?

>   - try to minimize the number of assertions in a given test.
>
may be we should try the approach listed in
http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/

Partha

> Cheers,
> -d
>
>