C. Titus Brown
ctb at msu.edu
Tue Apr 21 08:34:51 PDT 2009
On Tue, Apr 21, 2009 at 11:24:10AM -0400, Doug Hellmann wrote:
-> >-> It's a matter of choice: where do you want the complexity to lie?
-> >-> the framework designer's bucket, or the test designer's? I tend
-> >-> towards the latter obviously (consider the abstractions that Django
-> >-> provides).
-> >I'd rather it be simple. No complexity allowed. Didn't you read my
-> Maybe if you gave more detail about the nature of the complexity
-> you're thinking about adding we could give more direct answers.
It's across the board -- cleanup of intermediate files vs no cleanup;
pdb integration; order randomization; hooks to run test functions
before/after each test; test tagging; verification of what tests have
been run; test skipping; etc.
A lot of this sounds like something I'd use nose for, but we're trying
to keep things stdlib-ish. I've been arguing for keeping the test
runner as simple as possible and using nose with plugins for some of the
specialized stuff, but the boundary between customizing the test runner
and making use of nose plugins is still under discussion. (Hence this
One specific example -- we have our own 'get_suite' functions for each
test file, so that we can skip test suites when certain programs aren't
installed. I proposed to add unittest TestLoader test selection code
into our test runner (TestLoader.loadTestsFromName) so that we could run
individual tests easily, but that breaks the test suite skipping built
into get_suite(). So now I can backpatch SkipTest from python trunk
into a customized unittest version, OR I can develop a specialized test
loader, OR ... probably a lot of other things.
And I'm not sure what to do.
C. Titus Brown, ctb at msu.edu
More information about the testing-in-python