[TIP] Testify

[Mark Roddy]

On Fri, Oct 29, 2010 at 8:19 PM, Rhett Garber <rhettg at gmail.com> wrote:
>>
>> 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,
> not concept-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
>> well.
>
> 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
> between frameworks
> doesn't seem that interesting.
>
> Testify is indeed Yet Another Test Framework, but more ideas is better
> for everyone no ?
>
> Rhett
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>

Three things:

1) Obviously I'm not privy to all the details of your testing needs,
but I couldn't really see any pieces of functionality in testify that
couldn't be written in as nose plug-ins.  I think it's a much easier
sell to install a plugin for my existing tool than it is to completely
change frameworks due to having to possibly rework a lot of my test
code.  A thought: if testify has a plugin system, maybe move a bunch
of the functionality into plugins and then add some type of
compatibility layer so that we can use some of the features without
having to switch frameworks.

2)
>> "from testify import *" makes me frown.
>
> Yeah, but it's just so damn convenient..... It makes pyflakes frown too.
It frowns for a reason:

a.py:
class Bar(object):
    pass

b.py:
from a import *

c.py:
from b import *
<few hundred lines later>
def foo():
    b = Bar()

And you will have a horrible day trying to figure why foo() is no
longer working after someone renames or deletes Bar.


tldr:
Explicit is better than implicit.
http://www.python.org/dev/peps/pep-0020/

3) I think it's awesome whenever a company open sources any piece of
their code base so thank you Rhett and everyone else at Yelp.

-Mark