SoFunction
Updated on 2024-11-15

pytest explains fixture validity and sharing fixtures across files

fixture validity and sharing fixtures across files

i. fixture validity

The validity of a fixture means that a fixture function can only be requested if it is within its defined scope of use. For example, if a fixture is defined inside a class, then only test functions within that class can be requested. However, if the scope of a fixture is defined for an entire module, then every test function under that module can be requested.

Here is another parameter that affects the validity of the fixtureautouse=TrueThe default is False, if it is equal to True, the fixture will be executed before any other fixtures, there is a need to start a separate article later on, so I'll keep it short here.

Also, a fixture function can request any other fixture function. It doesn't matter where that requested fixture function is defined, as long as the test function requests them, the fixture function can.

Look at the sample code (in order to see the effect more intuitively, on the basis of the official code I added a few fixture function print):

#  content of test_module1.py 
import pytest
@
def order():
    print("\n run fixture function-order")
    return []
@
def outer(order, inner):
    print("Run the fixture function -outer")
    ("outer")
class TestOne:
    @
    def inner(self, order):
        print("Run the fixture-inner under TestOne.")
        ("one")
    def test_order(self, order, outer):
        assert order == ["one", "outer"]
class TestTwo:
    @
    def inner(self, order):
        print("Run the fixture-inner under TestTwo.")
        ("two")
    def test_order(self, order, outer):
        assert order == ["two", "outer"]

Attention:

  • Here's a fixture functionouterOutside of the test class
  • There are also 2 other names both of which areinnerfixture function, respectively, in the test classTestOnerespond in singingTestTwoCenter.
  • In the external fixture functionouterin which another request is made to the internal fixture functioninner。

Now I'll just run the classTestOne, look at the results of the run:

test_module1.py 
(of a computer) runfixturefunction (math.)-order
(of a computer) runTestOnelowerfixture-inner
(of a computer) runfixturefunction (math.)-outer
.                                                        [100%]
============================== 1 passed in 0.01s ==============================
Process finished with exit code 0

Indicates that the assertion in the test function passed. When the test function executes, the externalouterdemandinginnerbeTestOneDown. AlthoughTestOneunder theinnerThe only thing that can be done is toTestOneunder the test function. However, since the test function requests an externalouter, so the externalouterIt would also be possible to invite the internalinner。

An official schematic is also given, which can be understood in conjunction with the above ideas.

take note ofThe scope of the fixture definition is independent of the order in which it will be instantiated: the order of instantiation is enforced by the calling logic

can refer tohttps:///article/

II. Cross-file sharing of fixtures

If you put the fixture function into thefile, then the entire directory where this file is located can directly request the fixture inside without importing it.

In a real-world scenario, our test directories or packages may have multiple levels of nesting, in which case each directory can have a conftest file of its own. For example, like this:

What's in each tier is this:

tests/
    __init__.py
    
        # content of tests/
        import pytest
        @
        def order():
            return []
        @
        def top(order, innermost):
            ("top")
    test_top.py
        # content of tests/test_top.py
        import pytest
        @
        def innermost(order):
            ("innermost top")
        def test_order(order, top):
            assert order == ["innermost top", "top"]
    subpackage/
        __init__.py
        
            # content of tests/subpackage/
            import pytest
            @
            def mid(order):
                ("mid subpackage")
        test_subpackage.py
            # content of tests/subpackage/test_subpackage.py
            import pytest
            @
            def innermost(order, mid):
                ("innermost subpackage")
            def test_order(order, top):
                assert order == ["mid subpackage", "innermost subpackage", "top"]

Again, here's a scope boundary diagram to help understand.

Knowledge Points:

  • The order and top in the conftest under the top level are available to the current level and all of the lower levels (a circle corresponds to the respective scopes).
  • The test function can only search up the hierarchy for available fixture functions (out of the circle), but the out-of-circle lookup process can't go back into another circle to look down. So, tests/subpackage/test_subpackage.py::test_order can find the innermost defined in tests/subpackage/test_subpackage.py. However, another fixture defined in tests/test_top.py, which is also named innermost, can be found. which is also named eventually, is not available to test_order.

Actually, for the above, in my vernacular, if you want to use the fixture function in the conftest, you can only use the same or upper level. But you can't use any of the other directories or packages in the upper tier, and their lower tier conftests.

But reading the official docs, I think the official description of that circle is pretty good and more rigorous.

Above is pytest interpretation of fixture validity and cross-file sharing fixtures in detail, more information about pytest interpretation of fixture fixtures please pay attention to my other related articles!