On Thursday, October 27, 2011 08:54:12 Jacob Carlborg wrote: > On 2011-10-26 21:45, Jonathan M Davis wrote: > > On Wednesday, October 26, 2011 21:28:10 Jacob Carlborg wrote: > >> Well, in my library, if an assert error is thrown in a block (passed > >> to > >> the "it" method), the whole block is canceled and it will continue > >> with > >> the next block. So it's up to the user how the asserts should be laid > >> out.> > > It would be disastrous IMHO to continue to run a unittest block after an > > assert failed - at least in the general case. Too often further > > assertions relied on the state assured by the one that failed, so > > further failures just confuse things and give you too much data to have > > to sift through. As it stands with the built-in unit testing > > faciliities, you can put each assertion in its own unittest block if > > you really want each assertion to run on its own (though until it's > > fixed so that further unittest blocks within the module run after the > > first failure in that module, it wouldn't do you any good). > > > > - Jonathan M Davis > > My solution works now and if you want the whole unit test block to end > when an assert error is thrown that is possible too. Just call the "it" > method with a block once in a unit test block. > > You can never convince me that the other solution is better as long as > it doesn't work.
The current solution works just fine if you want a unittest block to terminate after a single assertion failure (as it should IMHO). It's just the running of subsequent unittest blocks within a module which doesn't work. And while I'd very much like it to work, I don't personally find it to be all that much of a problem. - Jonathan M Davis
