[TIP] Meta-test methods...
jnoller at gmail.com
Thu Apr 23 06:24:13 PDT 2009
On Thu, Apr 23, 2009 at 9:06 AM, Douglas Philips <dgou at mac.com> wrote:
>> -> Really glad I'm not using nose.
> Yes, it is full of all kinds of general functionality I do not need
> and is missing what I do need, which is why I have my own variant on
> unit test. And which is why I disagree with Jesse that nose is an
> appropriate substrate for functional and device testing. There might
> be a common substrate, but nose, or py.test, as they stand now, and as
> they have signaled their forward directions, are not it.
Oh crap, I better go rewrite the few thousand tests I have running
inside of them, which are largely function, long running tests. I knew
I was doing something wrong. All these damned test generators which
work exceedingly well for me must be turdlings of the turd
Oh wait. That's right: Nose (and py.test) finds tests and executes
them. It offers some tools which, if you want, you can use, otherwise
you can stick to pure discovery and execution. You can even alter the
behavior of discovery and execution via plugins.
I don't have some hyperactive view of frameworks or test runners where
I refuse to use them if:
A> The contain some bit I don't need
B> The internal code doesn't fit my world view (otherwise, I might not
be using python entirely... I have this thing about threads you
C> I hate writing my own stuff
I would rather take something already in the wild, customize it where
needed, ignore the bits I don't need, and move on with my life. The
nice thing about adopting something like Nose is that my tests written
subclassing unittest.TestCase just work, and my tests which don't,
I know this is a philosophical difference: I would rather leverage
nose where I can then maintain a custom in house framework - I get
paid to ensure the quality of a product, not to screw with frameworks
all day. Ergo, mercenary-drive-development.
More information about the testing-in-python