Following up on the previous lecture, what if you need to share a fixture, not between the test inside the same file where the fixture function is located. But instead you want to share the fixture across all tests in the sub directories have your root directory. For instance, I have created a new folder on my D drive called fixture sharing. We can call this the root directory. In this directory, I have what's called a contest.py file, and the subdirectory named test, which contains the test underscore results.py file holding the actual tests. You can download all of these files from the notebook following this video.

Now, keep in mind that in this type of setup, you can define your fixture inside the context.py file located in the root directory in order to have the fixture available across all sub directories. You Now let's open up the confidence.py file. And looking at the code inside this file, you can easily notice that it is the exact same fixture function that I used in the previous video. Now moving on to the subdirectory, let me open up the test results.py file as well. And notice that this file contains three tests that reference the XY func fixture function from within the context dot p y file. Okay, each of these tests is using a different number for the desired decimal places when applying the round function.

This is just to differentiate between the three tests. Now let's run these tests in the command line and see the results. So the CD fixture underscore sharing, Enter. And now I'm going to move over to the sub directory. So CD test and now let's run the test. So by Test, dash dash disable warning, and now the name of the file containing the test test underscore results dot p y enter.

As you can see, all three tests passed as expected. What is the advantage of sharing fixtures? Well, let's get back to the file. And let me add some more code and also uncomment. The print functions in each of these tests. Also, I'm going to add assert zero to the end of each test.

At this point, the assert zero statements will make sure that that each test fails because zero is always evaluated as Boolean false. Remember, we need our tests to fail just to see a detailed trace back and inspect how the fixture is used. Let's save the file as it is right now. And now let's run it once again inside the command line. Okay. Now, back to our question.

What is the benefit of fixture sharing? Well, if If you look carefully in this output, you will see the results of printing the memory location. So print of ID of x, y func. So you can see the results of printing the memory location of the x, y func object, the ID is the same for all the tests. And for the third test right here. This means that these three test functions run as fast as a single function, because they are reusing the same instance of x y func.

This can be really helpful, especially when the fixture function needs to connect to a remote server. For example, instead of creating a new connection, a new instance for each test, fixture sharing allows multiple tests to reuse the same instance. Let me undo my code changes. Okay, I'm going to save the file once again. Now let's get back to the test.py file for a bit. Notice something new here compared with previous vs video, the addition of the scope parameter to pi test dot fixture.

Now depending on your testing setup and needs, you can choose to share fixtures at five different levels, function class, module, package and session, and you can pick the desired level by passing it to the scope parameter. In my case, I want the fixture function to be available to test modules, such as my test underscore results.py file. So we want this fixture function to be available to all the test modules residing in any sub directories have the root directory, that's why I have provided the module string as a value for the scope parameter. Another thing that I want to mention here is that you can have constants.pi files containing fixture functions in your sub directories as well. Remember that fixture functions defined inside the root directory contest. UI file, as we have right here, these fixture functions are available to all the tests in all the sub directories.

Whilst fixture functions defined in a confidence.py file located in a sub directory, are available only for the test in that sub directory and its own sub directories, if any. Next let's talk a bit about fixture finalization as well. This refers to executing specific code when the fixture goes out of scope. So as soon as a module level fixture has been shared among all the tests in the module, and the last test in the module has finished its execution, we can use the yield statement. Actually, let me prove this to you. Let me show this to you.

In another folder that I have created picture underscore fin. So let's open up the confidence.py file from here and this is the yield statement I was talking about. So as soon as the last test in the module has finished execution, we can use the yield statement instead of the return statement, as we had here, in the previous example, the yield statement signaling that all the code following it should be executed serving as teardown code. Actually, let me explain this using an example. For instance, you are opening up a connection to a database server, and you read data from that database in order to run the tests inside the module. As soon as the last test finishes its execution.

Regardless of the test results, you can use the teardown code after the yield statement in your fixture function to properly close the connection to the database server. Now, if we look at this new folder right here, fixture underscore fin, it has the exact same structure as before the conference.py file and a subdirectory containing the tests. You can download the contents of this folder from the notebook, following the video. Now looking at the code from this new contest.py file, the difference lays in the fixture function. Previously, we had the return statement inside the fixture function. Here it is once again, with no other additional code.

This time we want to execute a piece of code as soon as the last test has finished its execution. This is why we need to replace return with the yield statement, followed by the desired tear down code. In my case, just a simple print function, the rest of the code inside context dot p y stays the same. The test functions stay the same, actually, let me prove this to you. So the test functions are exactly the same. Now let's run our tests to see if the teardown code gets executed or not.

Keep in mind that you need to use the dash s option as well in order to see the results of running the teardown code. So I'm going to move over To the other folder, that would be CD fixture, Finn CD test. And finally, we have pi test, dash s, also dash dash, disable warning, and finally, the name of the file test results.pi. And indeed, there it is. There's the code being executed the code following the yield statement. Now the last thing I want to mention in this video is that you can use another way of inserting teardown code without using the yield statement.

If you look into my test documentation, you will find out that you can also use what's called a finalizer function. also keeping the old return statement, the finalizer function has to be defined inside the fixture function. So there it is right here, right before the return statement. The role of the finalizar function is the same executing teardown code after the last step. finishes its execution. As a small homework, check out the link attached to this lecture and research the implementation and advantages of the finalizer function.

Then check out the code in the notebook following this lecture and I will see you in the next video.