pytest offers a core set of productivity features to filter and optimize your tests along with a flexible plugin system that extends its value even further. Whether you have a huge legacy unittest suite or you’re starting a new project from scratch, pytest has something to offer you.

In this video course, you learned how to use:

Fixtures for handling test dependencies, state, and reusable functionality
Marks for categorizing tests and limiting access to external resources
Parametrization for reducing duplicated code between tests
Durations to identify your slowest tests
Plugins for integrating with other frameworks and testing tools

If you’d like to learn more about the concepts in this video course, check out:

Download

Sample Code (.zip)

6.2 KB

Download

Course Slides (.pdf)

1.0 MB

Congratulations, you made it to the end of the course! What’s your #1 takeaway or favorite thing you learned? How are you going to put your newfound skills to use? Leave a comment in the discussion section and let us know.

00:00 In the previous lesson, I showed you how to use the parametrize mark to feed data to your tests. In this lesson, I’ll summarize the course and point you at some pytest plugins.

00:11 pytest is a popular alternative to the standard library’s unittest framework. It allows you to write less boilerplate code than unittest and provides fixtures to manage your test data.

00:23 The conftest.py file is a single place where you can store fixtures, monkey patches, or anything else that is common across your tests. And the oddly spelled parametrize allows you to feed different kinds of data to the same test, with a beautiful amount of info in the failure messages.

00:43 If you want to learn more, here’s the link to the well-written pytest documentation. pytest also supports plugins that either change its behavior or provide extra fixtures for you to use. Some popular ones are pytest-randomly.

00:59 This makes sure that the test suite is run in random order, which can help catch problems caused by stateful code. pytest-cov integrates the coverage library that measures how much of your code was run by the tests.

01:13 It’s a common best practice for coding teams to have a minimum coverage number, and the coverage tool measures this for you. pytest-django provides some fixtures that are useful if you’re testing Django code. And pytest-bdd gives you behavior driven development goodness by integrating with the Gherkin language from the Cucumber test mechanism.

01:36 Thanks for your attention. Oh, and that estimate you made—with apologies to Limp Bizkit, if I say test just 3 more times, that’ll be 184 tests in this testing rhyme.

01:48 I hope you enjoyed the course.

FooledByCode on June 22, 2022

Short and crisp, to the point, enough to get started. On thoughts of code coverage, where I work teams usually use SonarCube to get the estimated code coverage and many other things like security threats, security hot-spots, etc.

Christopher Trudeau RP Team on June 23, 2022

Yep, SonarQube is a great tool. I often have my teams use the coverage library as part of their local setup and then have SQ at the pull-request level.

FooledByCode on June 23, 2022

That’s exactly how we do it too.

Robert Curtiss on March 30, 2023

thank you, brief and very informative. I prefer this format, perhaps with a couple of brief tutorials building on the previous one. After completing each one, take a break to put in use what you have learned, and come back later to learn some advanced features. Cheers Bob

leonstarr on July 13, 2023

So I finally decided to get serious about testing and your tutorial was extremely helpful! Nice work. (and here comes the but… part). You left something extremely important out.

I get my repo all organized with the src/tests layout and inside my tests directory I create a simple test that imports one of my modules in the src folder. ModuleNotFoundError Ackk! I checked out the realpython-reader repo. No help. Eventually it occurs to me that there must be some way to tell pytest the source path in my repo. After the usual stackoverflow, googling etc. I realized that I needed to do this:

pytest.ini: [pytest] pythonpath = src

AND, put that file in my ABOVE the tests dir. This little gem would have been nice to know before getting started. (I see that there are a variety of other ways to get the same result, but this worked for me).

leonstarr on July 13, 2023

Oops, I scrambled code formatting:

In pytest.ini, above the tests dir

[pytest]
pythonpath = src

Christopher Trudeau RP Team on July 15, 2023

Hi Leon,

Thanks for the comment. At the time this content was put together I didn’t tend to use a src directory myself, hence why I didn’t run into this problem. The packaging landscape is still changing quite a bit in Python and even a year on, best practices are different.

Hopefully your comment will help anyone else who have run into this challenge.

Become a Member to join the conversation.

Testing Your Code With pytest (Summary)