There should be one test or two?

Testing RSpec
1

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

2

Hi Zhenning,

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

[1]

On 27 Aug 2010, at 06:43, Zhenning G. 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
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

cheers,
Matt

http://blog.mattwynne.net
+44(0)7974 430184

3

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.

4

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

5

On Fri, Aug 27, 2010 at 02:43, Zhenning G. [email protected]
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.

6

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.