Use pytest fixtures to reduce duplicated code across unit tests

Will Button
InstructorWill Button
Share this video with your friends

Social Share Links

Send Tweet
Published 7 years ago
Updated 6 years ago

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.

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.

egghead
egghead
~ 2 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today