summaryrefslogtreecommitdiff
path: root/doc/en/xunit_setup.rst
blob: 4fea863be63c919447449dec29d1478c7b74672f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

.. _`classic xunit`:
.. _xunitsetup:

classic xunit-style setup
========================================

This section describes a classic and popular way how you can implement
fixtures (setup and teardown test state) on a per-module/class/function basis.


.. note::

    While these setup/teardown methods are simple and familiar to those
    coming from a ``unittest`` or ``nose`` background, you may also consider
    using pytest's more powerful :ref:`fixture mechanism
    <fixture>` which leverages the concept of dependency injection, allowing
    for a more modular and more scalable approach for managing test state,
    especially for larger projects and for functional testing.  You can
    mix both fixture mechanisms in the same file but
    test methods of ``unittest.TestCase`` subclasses
    cannot receive fixture arguments.


Module level setup/teardown
--------------------------------------

If you have multiple test functions and test classes in a single
module you can optionally implement the following fixture methods
which will usually be called once for all the functions:

.. code-block:: python

    def setup_module(module):
        """ setup any state specific to the execution of the given module."""


    def teardown_module(module):
        """teardown any state that was previously setup with a setup_module
        method.
        """

As of pytest-3.0, the ``module`` parameter is optional.

Class level setup/teardown
----------------------------------

Similarly, the following methods are called at class level before
and after all test methods of the class are called:

.. code-block:: python

    @classmethod
    def setup_class(cls):
        """setup any state specific to the execution of the given class (which
        usually contains tests).
        """


    @classmethod
    def teardown_class(cls):
        """teardown any state that was previously setup with a call to
        setup_class.
        """

Method and function level setup/teardown
-----------------------------------------------

Similarly, the following methods are called around each method invocation:

.. code-block:: python

    def setup_method(self, method):
        """setup any state tied to the execution of the given method in a
        class.  setup_method is invoked for every test method of a class.
        """


    def teardown_method(self, method):
        """teardown any state that was previously setup with a setup_method
        call.
        """

As of pytest-3.0, the ``method`` parameter is optional.

If you would rather define test functions directly at module level
you can also use the following functions to implement fixtures:

.. code-block:: python

    def setup_function(function):
        """setup any state tied to the execution of the given function.
        Invoked for every test function in the module.
        """


    def teardown_function(function):
        """teardown any state that was previously setup with a setup_function
        call.
        """

As of pytest-3.0, the ``function`` parameter is optional.

Remarks:

* It is possible for setup/teardown pairs to be invoked multiple times
  per testing process.

* teardown functions are not called if the corresponding setup function existed
  and failed/was skipped.

* Prior to pytest-4.2, xunit-style functions did not obey the scope rules of fixtures, so
  it was possible, for example, for a ``setup_method`` to be called before a
  session-scoped autouse fixture.

  Now the xunit-style functions are integrated with the fixture mechanism and obey the proper
  scope rules of fixtures involved in the call.

.. _`unittest.py module`: http://docs.python.org/library/unittest.html