pytest-dev / pytest-dev/pytest
New scope designed for parametrized tests functions
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 14.5k
- Forks
- 3.4k
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 35
Description
Today I came across with an issue that I couldn't solve nicely with pytest, basically due to the lack of another level of granularity for the scope related with the fixtures, so let me give you an example:
class TestFoo:
@pytest.fixture
def db(self):
db.insert(['foo', 'bar'])
yield db
db.delete()
@pytest.parametrize('param',[
'foo',
'bar'
])
def test_search(self, db):
assert db.search(param)
def test_insert(self, db):
assert db.insert('x')
The previous snippet shows a simple example of a test class that has two different tests, one of them parametrized that will end up executing many times the same test and another test function that will be called just once, it's not parametrized. The fixture will be instantiated as many times as many tests we have, also considering the different instances of the test_search that is parametrized.
If we want to reuse the fixture, let's think that the fixture implies insert many documents in a DB and later in the teardown delete these documents, we have to change the scope of the fixture. Perhaps using the class scope.
As the example shows the fixture in the first test does not imply mutate it, so can be reused securely at least within the first test. The main problem with this scenario is the test that checks the insert, this test will mutate the fixture so the class scope can't be used as it is.
So to circumvent this issue, either we have to move the tests to another class to avoid the intersection or create some specific fixtures ad-hoc within the same class.
My proposal here is implementing a new scope called parametrize. This scope will suppose for those tests that are parametrized reuse the fixtures that have been marked with this scope and for those test that are not parametrized the scope will be considered just as a function scope.
Comments?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the issue's parametrized-test and fixture examples, focusing on how fixture reuse differs between parametrized and non-parametrized tests. Define the intended behavior of a new parametrize scope, including teardown and mutation cases, and add tests covering both kinds of test functions. The issue names no files or existing test entry points, so locating the fixture-scope implementation is part of the work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100