On Wed, May 27, 2009 at 4:07 AM, Matt Wynne <m...@mattwynne.net> wrote: > > On 27 May 2009, at 03:38, Julian Leviston wrote: > >> On 27/05/2009, at 9:33 AM, Gary Lin wrote: >> >>> Hi, >>> >>> 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? >> >> Julian. > > 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 > > <antipattern> > it "should do foo and bar" do > set_up_state > do_something_to_system_under_test > > assert_that_foo_was_done > assert_that_bar_was_done > end > </antipattern>
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 > set_up_state > do_something_to_system_under_test > end > > it "should have done foo" do > assert_that_foo_was_done > end > > it "should have done bar" do > assert_that_bar_was_done > end 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 > http://beta.songkick.com > http://blog.mattwynne.net > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
