Forum: RSpec there should be one test or two?

Posted by Zhenning Guan (rubyernewbie)
on 2010-08-27 07:43
in real world, when user deposit money into their bank, bank have money
and can check deposit record. so what would it be in rspec?

it 'should be deposit $10'
  user.bank.deposit(10)
  user.bank.deposit.saving.should == 10
end

about test , should be deposit $10 is clear? maybe 'should deposit $10
success'?

and when deposit, we should have a deposit record. added another test?

it 'should be a deposit record when deposit $10'
  user.bank.deposit(10)
  user.deposit_record.should == #something.
end

or just mixed it in one test?

it 'should be deposit $10'
  user.bank.deposit(10)
  user.bank.deposit.saving.should == 10
  user.deposit_record.should == #something.
end
Posted by Matt Wynne (mattwynne)
on 2010-08-27 20:09
(Received via mailing list)
Hi Zhenning,

One assertion per test [1] is a good rule of thumb, but don't get too 
hung up about it.

[1] 
http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html

On 27 Aug 2010, at 06:43, Zhenning Guan wrote:

> 
>  user.bank.deposit(10)
>  user.bank.deposit.saving.should == 10
>  user.deposit_record.should == #something.
> end
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

cheers,
Matt

http://blog.mattwynne.net
+44(0)7974 430184
Posted by Justin Ko (Guest)
on 2010-08-27 23:55
(Received via mailing list)
The "best practice" in your situation is to have two specs like so:

describe "#deposit" do
  it 'adds $10 to a savings account' do
    user.bank.deposit(10)
    user.bank.deposit.saving.should == 10
  end

  it 'creates a deposit record' do
    user.bank.deposit(10)
    user.deposit_record.should == #something.
  end
end

There are two downsides to having multiple expectations (should's) in
one example/spec:

1.) If the first expectation fails, the second one will not run.
    false.should be_true # fails
    false.should be_false # never runs

2.) It is much more simple for the description of the example/spec to
specify one expected behaviour. If you did something like this:
    it "deposits $10 to a savings account and adds a new record"
    You would have to remember that you're checking for TWO
behaviours, which is not as clear and direct as one.

Hope this helps.
Posted by David Chelimsky (Guest)
on 2010-08-28 00:17
(Received via mailing list)
On Aug 27, 2010, at 1:36 AM, Justin Ko wrote:

>    user.deposit_record.should == #something.
> 2.) It is much more simple for the description of the example/spec to
> specify one expected behaviour. If you did something like this:
>    it "deposits $10 to a savings account and adds a new record"
>    You would have to remember that you're checking for TWO
> behaviours, which is not as clear and direct as one.

There's also an upside to separating the examples (it's not all avoiding 
negatives), which is that you express the spec more accurately. Consider 
the output (slightly rephrased):

Account
  #deposit
    increases the balance
    creates a deposit record

Now it _looks like_ a spec.

HTH,
David
Posted by Myron Marston (Guest)
on 2010-08-28 02:00
(Received via mailing list)
> One assertion per test [1] is a good rule of thumb, but don't get too hung up about it.

To rephrase this slightly, you should test one behavior per spec, and
having multiple assertions or expectations in the same test is a good
sign that you may be testing multiple behaviors.
Posted by J. B. Rainsberger (Guest)
on 2010-09-06 16:39
(Received via mailing list)
On Fri, Aug 27, 2010 at 02:43, Zhenning Guan <lists@ruby-forum.com> 
wrote:

> in real world, when user deposit money into their bank, bank have money
> and can check deposit record. so what would it be in rspec?

I prefer two specs, because you are checking two unrelated things:
bank account balance and transaction record.

In general, I like to put each check in a separate spec, then combine
checks if I see they are related. This is my style.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice :: Agile
2010: Learn. Practice. Explore.
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.