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
on 2010-08-27 07:43
on 2010-08-27 20:09
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
on 2010-08-27 23:55
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.
on 2010-08-28 00:17
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
on 2010-08-28 02:00
> 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.
on 2010-09-06 16:39
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
Log in with Google account | Log in with Yahoo account
No account? Register here.