Mailman 3 June 2018 - pytest-dev

tips on writing a plugin for a third-party test framework?
by Harry Percival June 29, 2018

June 29, 2018

hi there, at work we use a test framework called "Contexts": http://contexts.readthedocs.io/en/v0.11.2/ it's basically a syntax for declaring tests using a given/when/then kind of syntax, using classes and special methods. as a way of structuring your tests it's... fine, once you get used to it. as a test runner and assertion framework it's fairly primitive. so i'd like to write a pytest plugin for it that basically just re-uses the parts of it that know how to recognise given/when/then bits, and then just use pytest as the test runner and assertion library. any pointers for how to get started? i thought i'd get a prototype started just based on `conftest.py`, and I've found the `pytest_pycollect_makeitem` which seems to be a good place to intercept for collecting tests, but I don't know what it's supposed to return (an "Item"? what's that? docs are minimal) or how to provide info about setup and teardown methods, which I guess would need to become fixtures somehow, but how would I associate them with a test method? maybe there's some example code somewhere i could look at? i tried peeking at pytest-bdd but it seems to be doing things at a lower level... hp

2 3

What is the best practice for tests that install python packages and run their tests?
by Vasily Kuznetsov June 23, 2018

June 23, 2018

Hello, everyone! Some time ago I wrote a pytest plugin [1] that helps with testing of scripts declared by 'console_scripts' entry point in setup.py. The tests of this plugin install a test package (let's call it TP) and then run TP's tests that are verifying that the scripts declared by TP's setup.py work as expected. TP is installed into the same python environment that runs the outer tests (uninstalled at fixture cleanup) and then the inner tests are run with the same pytest instance that runs the outer tests. This approach is somewhat dirty, but it works fine with disposable virtualenvs that we get from Tox. In the process of trying to package this plugin for Fedora it turned out that my test approach doesn't work with the way they run tests. They use system python so my tests try to install things into system python, don't have permissions and fail (see [2]). I think this could be fixed by creating a virtualenv in tmpdir and using that to install TP and run its tests. However, this new virtualenv would need to have pytest and pytest-console-scripts installed in it in order to run the inner tests. I'm planning to look into the ways to make a virtualenv inherit packages from another virtualenv (or from system python, as would be the case with Fedora package testing) but before I go into all this, I thought I would ask around if maybe there's a better way. Have any of you had situations where your tests needed to install packages and run their tests and how did you go about this? Thanks, Vasily [1]: https://pypi.org/project/pytest-console-scripts/ [2]: https://github.com/kvas-it/pytest-console-scripts/issues/11

3 2

pytest 3.6.1
by Bruno Oliveira June 5, 2018

June 5, 2018

pytest 3.6.1 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at http://doc.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Jeffrey Rackauckas * Miro Hrončok * Niklas Meinzer * Oliver Bestwalter * Ronny Pfannschmidt Happy testing, The pytest Development Team

1 0