[pytest-dev] process for replacing yield tests with modern style
flub at devork.be
Thu Oct 20 15:08:08 EDT 2016
On 29 August 2016 at 09:31, Ronny Pfannschmidt <rpfannsc at redhat.com> wrote:
> Hi Chris,
> currently there is no easy/good Replacement for the use-case you outline.
> the "correct" way would be a custom py.test specific collector
Yeah, a custom collector is the way to go here. I agree that it was
never really the correct way to do this.
http://docs.pytest.org/en/latest/example/nonpython.html describes how
you want to go about this I think.
> note that it was mostly luck this worked at all - ever since py.test
> switched to collect first yield tests where semantically broken due to
> running and destroying their own setupstate at collection time
> -- Ronny
> 2016-08-24 14:31 GMT+02:00 Chris Dent <cdent at anticdent.org>:
>> Several years ago I developed a relative simple YAML-based way of
>> doing HTTP tests. The processed turned yaml into tests and yielded
>> them for pytest to collect. At the time yield was the pytest
>> approved way of doing such things. That's here:
>> A few years later I took that idea and turned it into gabbi.
>> Because of local constraints (OpenStack) gabbi needed to be unittest,
>> subunit and testrepository compliant and oriented. Only later, and in
>> rather a hurry, did I add pytest support, using the yield style that I
>> already knew.
>> It's a bit of hacky mess because the tests are ordered
>> unittest.TestCases inside a unittest.TestSuite that has fixtures in
>> the scope of the TestSuite. Each yaml file becomes a TestSuite.
>> For the pytest side of things, plugin code uses the modifyitems
>> hooks to get the fixtures working effectively. Some "driver" code
>> yields tests to a user-code for loading the tests.
>> I recognize that this is all a bit messy, but it does the job. Now,
>> with the advent of pytest 3.x yield tests are deprecated and I'm not
>> sure of the correct way to get the same behavior in modern-style.
>> I'm aware of solutions for using yaml files themselves as the test
>> files but that would be a problem for existing deployed tests
>> that use the style shown in  and would also require conftest.py
>> or command line arguments and what I'm hoping to maintain is a way
>> for unadorned discovery to work and for the gabbi tests to be fairly
>> integrated with other tests.
>> I can certainly migrate to the  style but I see this as a good
>> opportunity to learn more of the details of how pytest generates
>> tests and use it. Can anyone give me some pointers please?
>> Thanks very much.
>>  https://gabbi.readthedocs.io/
>>  https://github.com/cdent/gabbi/blob/master/gabbi/pytester.py
>> Chris Dent ┬─┬ノ( º _ ºノ) https://anticdent.org/
>> freenode: cdent tw: @anticdent
>> pytest-dev mailing list
>> pytest-dev at python.org
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill,
> Eric Shander
> pytest-dev mailing list
> pytest-dev at python.org
More information about the pytest-dev