dgou at mac.com
Wed Apr 22 07:21:27 PDT 2009
On or about 2009 Apr 22, at 9:45 AM, Ned Batchelder indited:
> I'm coming late to this,
Better late than never! Welcome to the fray!
> more complex. The natural impulse is to factor common complexity
> out of
> the tests into something else. That other thing is the test
Maybe, or maybe just some intermediate places. It depends on how you
define 'framework.' In my case, we have a customized version of
unittest where the most general abstractions live, but then we also
have other layers of TestCase subclasses which only apply to certain
kinds of tests. I would not classify those intermediate subclasses as
part of the framework since they aren't general enough. Just saying
that isn't so black and white and "in the test or in the framework." :)
>> I'd rather it be simple. No complexity allowed. Didn't you read my
>> blog post??
> 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.
I can't speak for Titus, but the point of this is to say: "No, we
don't just accept complexity, we want to critically examine just how
much complexity we actually need to have." Most of the times when I've
done I've found that its far to easy for most people, myself included,
to accept complexity as needed when it actually isn't.
> ... The best way to get
> rid of complexity is to outsource it to someone else.
That may be expedient and convenient, but it isn't getting rid of the
complexity, it is just moving it around.
> Then you don't have to maintain it, but you still get to benefit
> from its power.
There is lots of power in nose and py.test that I. do. not. need. I do
not benefit from it. I am hurt by it, and thus I have, to date, chosen
not to use it. The ROI is way too low. Can't speak for Titus.
More information about the testing-in-python