Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Use pytest fixtures to reduce duplicated code across unit tests

    Will ButtonWill Button

    In this lesson, you will learn how to implement pytest fixtures. Many unit tests have the same resource requirements. For example, an instantiated object from a class. You will learn how to create the instance of the class one time as a fixture and reuse that object across all your tests. This results in faster tests, eliminates duplicate code, and uses less resources when running your tests.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson


    Instructor: 00:02 On the left, we've got our Python class that defines our self-driving car, and on the right, we have the unit test to validate each of the functions. When you look through each of these unit tests, though, you'll see that each unit test defines a new instance of the car class.

    00:19 That duplicates code, it duplicates resources, and ultimately makes me not want to run my tests. We're going to change that. I'm going to start by running all of my tests here, and show you that they all pass. There it is, all four of them passed.

    00:34 Now, we're going to define a pytest fixture, and set the scope equal to module. We'll come back to that in a minute. Create a new function called myCar, and all that myCar is going to do is return an instance of the car class that's been initialized.

    00:53 With that, I can change my functions for my test to get rid of the part where we initialize the car, and just pass in that fixture that we created. Let's now run our tests again. Again, all four tests pass, but this time, they're all using shared fixture, rather than each of them defining their own instance of the class.

    01:20 We've got this scope equals module thing here, and I told you we would come back to that. What this means is that this fixture defined right here is shared by all the tests within this class. By default, pytest fixtures have a scope of function, meaning that each function gets its own instance of the fixture.

    01:42 We don't really want that, because in cases where the fixture takes a while to spin up, or consumes a lot of resources, it just duplicates, and makes things run slower than they should. To illustrate what that means, we're going to take a look at this accelerate function.

    01:56 If we look at the code for it over here, we can see that the accelerate function increments the speed of the car by 10. I'm going to take this function, and I'm going to copy it, give it a new name. We'll save that.

    02:17 If I run the first accelerate function, it passes. Then if I run the second accelerate function, it passes as well. Now, watch if I run all the unit tests. One failed. Whenever we scroll, back up here, we see that the accelerate one function fails, because the speed was 20.

    02:41 What that shows us is that all of the tests are sharing this same fixture. Our first accelerate function accelerated the car to the speed of 10. Whenever the second accelerate ran its test, the speed was already 10. Whenever it incremented it by another 10, the result was 20.