skipping one unittest assertion?

[Ben Finney]

Roy Smith <roy at panix.com> writes:

>  Ben Finney <ben+python at benfinney.id.au> wrote:
>
> > Each test case should be testing one thing: if it fails, it should be
> > for exactly one reason.
>
> Well, yeah, that's certainly the XP/unit-test doctrine. In practice
> however, tests often get written as "do a bunch of stuff to get some
> result, then make a bunch of assertions about that result".

And the result is an increasingly-difficult maintenance burden for the
test suite, as you've discovered.

> Sure, you could make each of those assertions a distinct method, and 
> factor the "do a bunch of stuff" into setUp().  Which probably means 
> factoring those methods out into a new TestCase subclass.  At some 
> point, however practicality trumps doctrine.

Yet practicality, i.e. making your test cases manageable, is exactly
what you don't have with your current approach. I'm not quoting doctrine
at you; I'm saying that *because of problems like you're encountering*,
you should refactor your test cases to do one test per case.

-- 
 \        “Absurdity, n. A statement or belief manifestly inconsistent |
  `\            with one's own opinion.” —Ambrose Bierce, _The Devil's |
_o__)                                                Dictionary_, 1906 |
Ben Finney