As our Python codebases grow larger, so do our test suites tend to extend. This usually results in a significant increase in the time that our different tests (unit, integration, end-to-end, etc.) need to complete.

Long-running tests can negatively affect the development process in multiple ways, for example:
- Slower development (Definition of Done should include proper testing), hurting the sense of productivity
- Slower and less code-feedback cycles (code reviews)
- It can take more time to bring a hotfix out to production
- Additional budget being spent on CI/CD pipelines

This talk aims to point out methods that can help you immediately address a slow test suite, as well as ways to structure your set of tests later on, to improve even more.

We will discuss how to handle these problems after they are detected. In general, it is important to first measure and pinpoint possible bottlenecks before proceeding to any improvements. As they say, “Premature optimization is the root of all evil.”...

The methods will be presented starting from the simplest to apply, up to the more niche gotchas that I have gathered throughout my journey as a Python developer. Each method will be accompanied by a simple example, that will also be available on GitHub for the attendants.
We will mainly be using pytest as our test runner, being one of the most popular ones, and also providing quite a useful toolset. To name a few of the techniques that we will go over:
- Distributed CPU testing
- Parallel testing
- Fixture lifecycle evaluation
- Package caching
- Separating what to test from how to test it (choosing the right abstractions)

In conclusion, after completing the talk you should have found out ways to improve the time your tests need to complete, that you can apply already from the next day, but also how to structure your tests in the future to ensure better outcomes.