On 29 August 2016 at 09:31, Ronny Pfannschmidt <[email protected]> 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. Regards, Floris > 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 <[email protected]>: >> >> >> 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/2bd1c803b71bd26be7822be87e249a811467b863/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 >> [email protected] >> 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 > > > _______________________________________________ > pytest-dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/pytest-dev > _______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
