[Python-ideas] Test Class setup and teardown in unittest

[Holger Krekel]

On Thu, Jan 21, 2010 at 8:47 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> On Thu, 2010-01-21 at 11:42 +0000, Michael Foord wrote:
>> On 21/01/2010 01:37, Robert Collins wrote:
>> > core allowing fixtures to be shared across test instances in a way that
>> > doesn't prohibit their use with concurrent testing, doesn't make it
>> > awkward to do it across multiple classes.
>>
>> Can you demonstrate how testresources solves these problems.
>
> Yes. resources are declared in a list, which allows the test framework,
> when parallelising, to group together tests that use the same resources
> when partitioning. Compare this with setUpClass where all tests in an
> inheritance hierarchy have to be grouped together (after excluding your
> base TestCase).

FWIW I'd like to add that after a number of years of having py.test
support setup_class
and setup_module i came to the conclusion some time ago that this
"grouping" requirement is bad for functional tests which usually
require more setup management and parametrization than classic
unittests.  It's also not easy to have expensive setup easily shared
between test modules and it's easy to get this wrong and to in the end
hinder refactorings rather than to further it.

At least that's my and some of my users experience with it. And is the
reason why I came up with a new method to do test fixtures that allows
to directly manipulate setup state in a single place instead of all
across test suites. Basically test functions receive objects
("funcargs") that are created/handled in factories. Loose coupling
here allows to have the same setup used across many test modules
efficiently.  Obviously different from the testresources approach
although i share a number of related design considerations and goals.

cheers,
holger

> You ask in another mail for a SSCE: here is one attached to this mail
> ('foo.py'). Run with 'python -m unittest foo'.
>
>> > I'm happy to make any
>> > [reasonable] changes (including license) to testresources to make it
>> > includable in the stdlib if that's of interest.
>> >
>>
>> That's not how contributing code to Python works. You need to provide a
>> signed contributor agreement to the PSF and then you specifically
>> license to the PSF any code you are contributing using one of a few
>> specific licenses. For new modules in the standard library you also need
>> to be willing to maintain the code.
>
> There is other code of mine in the standard library unittest module,
> done without a contributor agreement: so this is at best inconsistent. I
> mention license changes because that would be required to include it in
> the standard library (its currently a copyleft license) - and I'm not
> the sole author. Regardless, whatever process and actions are needed, I
> will do them, or arrange with other people where needed.
>
> -Rob
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>