C. Titus Brown
ctb at msu.edu
Wed Apr 22 19:00:15 PDT 2009
On Wed, Apr 22, 2009 at 09:45:11AM -0400, Ned Batchelder wrote:
-> >I'd rather it be simple. No complexity allowed. Didn't you read my blog
-> I'm assuming this is hyperbole for dramatic effect. Of course we all
-> accept (and even create) complexity. The trick is to find the
-> Goldilocks point: not too little, not too much, just the right amount.
-> And then to wrap it in abstractions that don't leak too much.
Well, yes. But I find I have less tolerance for complexity than many
-> >A lot of this sounds like something I'd use nose for, but we're trying to
-> >keep things stdlib-ish.
-> Maybe this is the point to examine more closely. The best way to get
-> rid of complexity is to outsource it to someone else. Then you don't
-> have to maintain it, but you still get to benefit from its power. What
-> is it that is keeping you from requiring nose? Is it sacrilege to say
-> that it's ok to require 3rd-party stuff to run tests, since not all
-> users of the product will need to run the tests?
The last person to seriously refactor our test framework is anti-nose,
or at least not-pro-nose. Before that, we had a rather nasty
nose-derived hack necessitated by some design problems in the software;
those have now been resolved, so we could move back to nose, sans ugly
I think it's fine to use nose for things that will work out of the box
with nose, as long as they're not absolutely required to run the tests.
I may or may not be wrong ;)
Right now, I'm working on making the test code nose-compatible with a
specialized plug-in now, and that will let people experience the wonders
of nose with our current test code. I'm also trying to figure out how
to best divvy up our increasingly onerous test framework requirements
between custom code and nose plugins.
C. Titus Brown, ctb at msu.edu
More information about the testing-in-python