On Thu, Jan 21, 2010 at 8:47 PM, Robert Collins <robertc@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@python.org http://mail.python.org/mailman/listinfo/python-ideas