[pytest-dev] fixtures as context managers

[holger krekel]

On Thu, May 09, 2013 at 16:39 +0200, Ronny Pfannschmidt wrote:
> Hi all,
> 
> how about using proper context managers in all cases
> 
> if a class that implements the context manager protocol is marked as
> fixture, it can be used instead

Today, marking a class like this:

    @pytest.fixture
    class X:

will raise an error.  In the future, it could look at the __init__
and regard it as the fixture.  I don't think we should look at
__enter__ or __exit__ there.  After all the intention might be to
use it like this:

    def test_some(X):
        ...
        with X:
            ...

> so we would use
> 
> @pytest.fixture
> @contextlib.contextmanager
> def foo(...):
>   ...
> 
> however the contextlib stuff might be a bit messy to deal with
> so a pytest.contextmanager might be necessary

it might indeed be messy becaue contextlib returns another function.
Needs to be checked.

> im -1 on the flag

Why?  And wh is introducing a new "@fixturemanager" decorator which
duplicates the API better, in your oppinion?

cheers,
holger

> -- Ronny
> 
> On 05/09/2013 03:56 PM, holger krekel wrote:
> >Hi Bruno, Andreas, all,
> >
> >yesterday in my in-house course i demonstrated the change.  Somebody
> >pointed out rightly that with 2.3.5 you are allowed to do:
> >
> >     @pytest.fixture
> >     def genfix():
> >         yield 1
> >         yield 2
> >
> >Which means that when you write a test you can use the fixture as a generator:
> >
> >     def test_gen(genfix):
> >         for x in genfix:
> >             # ...
> >
> >This is probably used by very few people but to be on the safe side,
> >we probably should introduce a flag like this:
> >
> >     @pytest.fixture(ctx=True)  # signal this is a context manager style fixture
> >     def fix():
> >         yield 1
> >
> >What do you think?  Any other suggestions for the flag name?
> >
> >I'd rather not introduce something like @pytest.contextfixture
> >because it would be a duplication of the API (scope, params).
> >But i am open to be convinced otherwise.
> >
> >cheers,
> >holger
> >
> >
> >
> >On Sun, May 05, 2013 at 10:40 -0300, Bruno Oliveira wrote:
> >>Very nice! I always thought the "request.addfinalizer" mechanism somewhat
> >>cumbersome. :)
> >>
> >>
> >>On Sun, May 5, 2013 at 10:05 AM, holger krekel<holger at merlinux.eu>  wrote:
> >>
> >>>Hi all,
> >>>
> >>>after having been asked by Andreas Pelme and Vladimir Keleshev, repeatedly,
> >>>i finally tried to allow fixture functions to be context managers like
> >>>this:
> >>>
> >>>     @pytest.fixture
> >>>     def myfixture():
> >>>         print "setup"
> >>>         yield val
> >>>         print "teardown"
> >>>
> >>>With this, you don't need to use "request.addfinalizer" - pytest does
> >>>this by detecting your yield.  I checked this into trunk to allow
> >>>experimentation - it seems to work fine with scopes and parametrization.
> >>>For pytest, it's really just a slightly different "fixture function
> >>>calling"
> >>>protocol, contained in this commit:
> >>>
> >>>
> >>>https://bitbucket.org/hpk42/pytest/commits/b93ac0cdae02effaa3c136a681cc45bba757fe46
> >>>
> >>>Note that i don't plan to extend this yield mechanism to parametrization
> >>>as that would meanparametrization at test execution time, rather than at
> >>>collection time.  It would be both conceptually and implementation wise
> >>>hard to do i think.
> >>>
> >>>The change is committed to trunk, and you can also do:
> >>>
> >>>     pip install -i http://pypi.testrun.org -U pytest
> >>>
> >>>to get pytest-2.3.6.dev2 at least.
> >>>
> >>>feedback welcome, actually without people actively
> >>>wanting it, it might be thrown out again ;)
> >>>
> >>>holger
> >>>
> >>>
> >>>_______________________________________________
> >>>Pytest-dev mailing list
> >>>Pytest-dev at python.org
> >>>http://mail.python.org/mailman/listinfo/pytest-dev
> >>>
> >_______________________________________________
> >Pytest-dev mailing list
> >Pytest-dev at python.org
> >http://mail.python.org/mailman/listinfo/pytest-dev
>