-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Introduce "ids" argument to pytest.fixture #238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Original comment by Gustavo Picon (BitBucket: tabo, GitHub: tabo): I set params in a fixture, like:
And then used a I suppose adding an |
Original comment by Ronny Pfannschmidt (BitBucket: RonnyPfannschmidt, GitHub: RonnyPfannschmidt): i wonder - can we maybe accept OrderedDicts as params? |
Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42): i guess we could accept an Odict, but it's likely this dict is prepared somewhere else anyway and then splitting it into values and ids is not hard. What is more interesting is to allow specifying params=function which is called with the config object and can return values/ids. Currently you kind of have to revert to using pytest_generate_tests to achieve something similar. |
Original comment by Vinicius K. Ruoso (BitBucket: vkruoso, GitHub: vkruoso): I was looking at the pytest.org website and this came up: http://pytest.org/latest/fixture.html#parametrizing-a-fixture There is an example that uses the "ids" parameter on pytest.fixture:
I was trying to use this in my tests, but an error occur. Looking in the history for python.py file and concluded that support for passing a callable to the ids parameter was added by issue351. By the changelog in the site I can see that this is listed in version 2.7.0.dev, and of course the version I have (2.6.4) lack support for it. Why there is a feature documented on the main site that has not been released yet? This is confusing in my opinion. Thanks a lot. |
Original comment by Brianna Laugher (BitBucket: pfctdayelise, GitHub: pfctdayelise): Yes, this was added in a PR for #351 . @vkruoso you are not the only one who has been confused by the docs being ahead of the latest release. Adding documentation at time of writing the feature means the website might (will probably) get updated before the next release. Perhaps for new functionality, it should be required to mention in the docs what version it will be available in. But this could be hard to know, eg when there is a version bump. So........... Re release of 2.7, Holger mentioned on the pytest-dev list that he would like to make the release this week. |
Original comment by Vinicius K. Ruoso (BitBucket: vkruoso, GitHub: vkruoso): Thanks for the fast answer. Maybe the documentation should be built from a stable branch or something similar. It is very frustrating to read about a feature and not be able to use it in a stable release. Good to hear that 2.7 will be out soon. Will be waiting to use this feature. |
Original comment by Brianna Laugher (BitBucket: pfctdayelise, GitHub: pfctdayelise): Actually, the support for supplying ids as a list of strings to pytest.fixture was added in 2013-12 by @flub, although the docs showing the example with ids as a fn was added in 2014-10 (after the PR for issue 351). So pytest.fixture is using the same mechanism as pytest.mark.parametrize to create the test ids, although I'll admit I couldn't figure out precisely how. So the examples in the docs will work as specified in 2.7.0. I think Holger's comment about "allow specifying params=function" is more of a musing than a requirement for this issue, as stated in the title this issue is resolved. Specifying fixture params as a function could be reported a separate issue if it is not already, if anyone cares enough about it to do so. |
Originally reported by: Gustavo Picon (BitBucket: tabo, GitHub: tabo)
One of the things I missed when I ported a hacky dynamic unittest suite to pytest fixtures, was the information I got from the test names. I parametrize 6 different django models in every test, but in the report I saw something like:
Which wasn't helpful at all. I solved this problem by monkeypatching _pytest.python.idmaker. Now I have nicer results, like:
It would be better if pytest provided an interface for plugins to handle different object types, so for instance pytest_django could register itself as being in charge of formatting all django orm objects and views.
The text was updated successfully, but these errors were encountered: