Roy Smith <r...@panix.com> writes: > Ben Finney <ben+pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
