Testing Your Code With pytest (Summary)
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:
- pytest documentation
- Getting Started With Testing in Python
- Test-Driven Development With PyTest
- How to Provide Test Fixtures for Django Models in Pytest
- 4 Techniques for Testing Python Command-Line (CLI) Apps
- Build a Hash Table in Python With TDD
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.
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.
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.