[pytest-dev] process for replacing yield tests with modern style

Ronny Pfannschmidt rpfannsc at redhat.com
Mon Aug 29 04:31:47 EDT 2016


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

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:
>
>    https://github.com/tiddlyweb/tiddlyweb/blob/master/test/http_runner.py
>
> A few years later I took that idea and turned it into gabbi[1].
>
> 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[2] uses the modifyitems
> hooks to get the fixtures working effectively. Some "driver"[3] code
> yields tests to a user-code[4] 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[5] but that would be a problem for existing deployed tests
> that use the style shown in [4] 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 [5] 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.
>
> [1] https://gabbi.readthedocs.io/
> [2] https://github.com/cdent/gabbi/blob/master/gabbi/pytester.py
> [3] https://github.com/cdent/gabbi/blob/2bd1c803b71bd26be7822be8
> 7e249a811467b863/gabbi/driver.py#L111
> [4] https://github.com/cdent/gabbi/blob/master/gabbi/tests/test_
> gabbits_pytest.py
> [5] http://docs.pytest.org/en/latest/example/nonpython.html#a-
> basic-example-for-specifying-tests-in-yaml-files
>
> --
> Chris Dent               ┬─┬ノ( º _ ºノ)        https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20160829/209e998c/attachment.html>


More information about the pytest-dev mailing list