rhettg at gmail.com
Fri Oct 29 17:19:09 PDT 2010
> The blog post says nose and unittest2 didn't meet your needs, but
> doesn't say what those needs are. Also, you didn't mention py.test,
> have you looked at it at all?
I may have exaggerated since unittest2 was completely unknown to me
(or non-existant ?) when testify started in summer of 2009. py.test I
haven't heard of either.
I'll have to check that out.
The primary things missing at the time were easy ways to put tests into 'suites'
and smarter test running for parallelization. Having multiple
hierarchies of setup and teardown
was important. Also, the java based style (junit ?) syntax seemed... old school.
We spent some amount of time hacking in features to the built-in unittest but
eventually just gave up and started with a clean slate (code-wise,
> I like the --buckets idea. I'd once implemented a similar, but more
> limited idea: --odd/--even options for splitting the tests into two sets
> and running them in parallel on my dual-core laptop. It worked quite
Yeah we split our tests across 12 buildbot slaves.
> "from testify import *" makes me frown.
Yeah, but it's just so damn convenient..... It makes pyflakes frown too.
> Actually, the whole idea of
> "here's yet another Python testing framework, incompatible with all
> other Python testing frameworks" makes me sad.
I hear you. It's fairly easy to transition from unittest to testify,
but that's not the
same thing as compatibility. However, I think it's pretty rare for a
project to switch
test frameworks or migrate tests between projects, so compatibility
doesn't seem that interesting.
Testify is indeed Yet Another Test Framework, but more ideas is better
for everyone no ?
More information about the testing-in-python