[py-dev] reversing fixture/xunit setup call order?
Hi all, 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? holger
On 16 December 2012 12:23, holger krekel <holger@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. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
On Tue, Dec 18, 2012 at 21:11 +0100, Floris Bruynooghe wrote:
On 16 December 2012 12:23, holger krekel <holger@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
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. On Wed, Dec 19, 2012 at 1:42 AM, holger krekel <holger@merlinux.eu> wrote:
On Tue, Dec 18, 2012 at 21:11 +0100, Floris Bruynooghe wrote:
On 16 December 2012 12:23, holger krekel <holger@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
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 <holger@merlinux.eu> wrote:
On Tue, Dec 18, 2012 at 21:11 +0100, Floris Bruynooghe wrote:
On 16 December 2012 12:23, holger krekel <holger@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
participants (3)
-
Floris Bruynooghe -
holger krekel -
lahwran