On Wed, Dec 19, 2012 at 16:27 -0700, lahwran wrote:
> that looks good to me. I'm not sure I understand the reasoning behind
> having `clsarg(...) # @pytest.fixture("class", autouse=False)` come after
> setupClass, though.
The ideas is that implicit fixtures come before explicit ones.
All autouse=True fixtures are implicit - they are not requested explicitely
through a funcarg or a @pytest.mark.usefixtures(...) decoration.
best,
holger
> On Wed, Dec 19, 2012 at 1:42 AM, holger krekel <hol...@merlinux.eu> wrote:
>
> > On Tue, Dec 18, 2012 at 21:11 +0100, Floris Bruynooghe wrote:
> > > On 16 December 2012 12:23, holger krekel <hol...@merlinux.eu> wrote:
> > > > Currently, if you define e.g. an autouse fixture function it is going
> > to
> > > > be called _after_ the xUnit setup functions. This is especially
> > > > surprising when you do a session-scoped autouse fixture. I am
> > wondering
> > > > if we could reverse the order, i.e. call fixture functions (including
> > > > autouse-fixtures of course) ahead of xUnit setup methods.
> > > >
> > > > any thoughts?
> > >
> > > Agreed, I think it would be a good idea to have at least autouse
> > > fixtures before the xUnit setup.
> >
> > However, i realize we also have scopes. And this is where any attempt
> > to decide ordering between pytest versus xUnit fixtures seesm to break
> > down:
> >
> > - We don't want setup_class execute after a function-scoped pytest fixture.
> >
> > - We don't want class-scoped pytest fixture execute after setup_method.
> >
> > Maybe, we could internally add autouse-fixtures at module/class/function
> > scope which would look for setupX/teardownX and act accordingly. This
> > way xUnit setup/teardown methods would appear as pytest fixtures.
> > Here is an example how it could look like for a mix of
> > xUnit/pytest class/function scoped autouse- and non-autouse fixtures:
> >
> > user-function found by
> >
> > --------------------------------------------------------------------------
> > ...
> > autoclass(...) # @pytest.fixture(scope="class", autouse=True))
> > setup_class(cls) # internal @pytest.fixture("class", autouse=True)
> > clsarg(...) # @pytest.fixture("class", autouse=False)
> > funcfixture(...) # @pytest.fixture(scope="function", autouse=True)
> > setup_method() # internal @pytest.fixture("function", autouse=True)
> > arg1 # @pytest.fixture(scope="function", autouse=False))
> > ...
> > test_function(arg1, clsarg)
> > # teardowns execute in LIFO registration order
> >
> > Makes sense?
> >
> > Ideally, we could produce something like the above output with
> > some command line option to help debugging.
> >
> > best,
> > holger
> >
> > > Regards,
> > > Floris
> > >
> > >
> > > --
> > > Debian GNU/Linux -- The Power of Freedom
> > > www.debian.org | www.gnu.org | www.kernel.org
> > >
> > _______________________________________________
> > py-dev mailing list
> > py-dev@codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> >
> _______________________________________________
> py-dev mailing list
> py-dev@codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
