[rspec-users] Any way to continue on Assertion Failure
zach.dennis at gmail.com
Sat May 30 21:07:14 EDT 2009
On Wed, May 27, 2009 at 4:07 AM, Matt Wynne <matt at mattwynne.net> wrote:
> On 27 May 2009, at 03:38, Julian Leviston wrote:
>> On 27/05/2009, at 9:33 AM, Gary Lin wrote:
>>> I wonder if there is any way to tell the test script to continue even
>>> when encountering an assertion failure? The reason I am asking this is
>>> because I have a test flow that can take a long time to run and it would be
>>> very useful if I can perform all verification at the end of test flow in one
>>> shot rather than fail one and exit immediately. Of course, I could break
>>> each verification point into separate test case, but then it will double or
>>> triple the overall execution time. Does RSpec support this?
>> Isn't this usual behaviour?
> Yeah I'm a little confused by the question (and David's response) so maybe
> I've misunderstood something. Normal RSpec test runs will catch all the test
> failures and report them at the end of the run. I wonder whether the OP is
> talking about a situation where the interaction with the system takes a long
> time, so that using lots of examples of the desired behaviour causes that
> interaction to be run several times making the whole run very slow.
> I also wonder whether he's just thinking in the test/unit mindset, which I
> see a lot, where you have examples like this
> it "should do foo and bar" do
I don't know that I would call this an antipattern unless set_up_state
is duplicated across examples. I usually don't factor things out of an
example unless it's duplicated in another example (then I extract to a
before) or I'm working in a specific context (which I always give a
before since it provides meaning of the context in an explicit way).
> Here's my normal RSpec flow:
> before(:each) do
> it "should have done foo" do
> it "should have done bar" do
Most of the time I would leave the "do_something_to_system_under_test"
inside each example. I find it easier to read, and a more useful
example (since you don't have to go look else where to see how the
method is called), and it becomes easier to maintain should the object
change in a way that requires a specific pre-condition to be
introduced that aren't needed by the other examples (you don't have to
modify every other example).
another 2 cents to throw in the water fountain,
> if set_up_state and/or do_something_to_system_under_test take ages, you
> could use a before(:all) block instead, but that comes with obvious leaky
> state disadvantages.
> Matt Wynne
> rspec-users mailing list
> rspec-users at rubyforge.org
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
More information about the rspec-users