Skip to content
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

Fixture scope documentation #538

Closed
pytestbot opened this issue Jul 4, 2014 · 8 comments · Fixed by #2848
Closed

Fixture scope documentation #538

pytestbot opened this issue Jul 4, 2014 · 8 comments · Fixed by #2848
Labels
type: docs documentation improvement, missing or needing clarification type: enhancement new feature or API change, should be merged into features branch

Comments

@pytestbot
Copy link
Contributor

Originally reported by: Mark Stacey (BitBucket: Gudahtt, GitHub: Gudahtt)


The fixture documentation briefly mentions the possibility of a fixture with class scope in the beginning summary, but it isn't mentioned anywhere else in the document. I had to check the source code to see if this was possible.

Also, I didn't see any mention that the default scope was "function" - it was implied, but not explicit.

I think it would be helpful to include a full list of available scopes, and to explicitly say that function scope is default. Both of these things are included in the docstring for the fixture function in the source code:

#!python

:arg scope: the scope for which this fixture is shared, one of
                "function" (default), "class", "module", "session".

@pytestbot
Copy link
Contributor Author

Original comment by yuliang shao (BitBucket: markshao, GitHub: markshao):


agree to enhance the documentation

@pytestbot
Copy link
Contributor Author

Original comment by Sorin Sbarnea (BitBucket: sorin, GitHub: sorin):


I don't know I I should raise this as a different bug or keep it here. I wasn't able to find a solution for this in the documentaiton. I do have a set of unittests written using the python's unittest module. They are using the setUpModule() function to load a global variable with the shared "stuff" that is required to run the tests (including some http sesions).

When run normally my tests was running fine but with py.test they are failing. I patched it a little bit to make it run using the old pytest fixture functions (which happen not to have same names as unittest ones). Worked but only when not executed on multiple threads, and that's a feature I do want to use.

The documentation examples are useless in my case because I do have like 20 classes (unittest.TestCase) with 10 tests inside each class. Obviously I do not want to add a new parameter to each test.

Until now I used the class setUp() method to load the shared dictionare inside self.

@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


On Sat, Jul 19, 2014 at 07:49 -0000, yuliang shao wrote:

If someone can submit a PR for enhanced docs, i'd happily review and merge
them.

best,
holger

@pytestbot pytestbot added type: enhancement new feature or API change, should be merged into features branch type: docs documentation improvement, missing or needing clarification labels Jun 15, 2015
@DuncanBetts
Copy link
Contributor

I've read the documentation, and think the Sharing a fixture across tests in a module (or class/session) section makes this clear enough. Otherwise (this is a rough draft) how about:

Extending the previous example, we can add a scope='module' parameter to the @pytest.fixture invocation to cause the decorated smtp fixture function's default behaviour of invoking once per function, to instead only be invoked once per test module.

@nicoddemus
Copy link
Member

Where would you add that paragraph @DuncanBetts? Perhaps we can discuss this over the PR itself? 😁

@bilderbuchi
Copy link
Contributor

bilderbuchi commented Oct 16, 2017

I plan to take care of this issue. Most of it has been added to the docs in the meantime, just needs some rounding out of the relevant sections.

@nicoddemus
Copy link
Member

Awesome @bilderbuchi, thanks!

@bilderbuchi
Copy link
Contributor

Done, see #2848.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: docs documentation improvement, missing or needing clarification type: enhancement new feature or API change, should be merged into features branch
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants