So you’re a backend developer or data engineer and probably stumbled across this article when looking to speed up your Unit Tests.
TDD (Test driven development) is the practice of writing unit tests alongside the actual source code.
Why? Because it makes you think of edge cases and functionality you generally don’t think of when writing source code.
That’s great. But what about running these tests? Maybe 100s of tests?
Picture this: you’re writing tests for a complex Python application, and suddenly, you hit a wall.
Your code more often than not, depends on a database, external APIs, environment variables, or intricate global settings that seem impossible to isolate or control.
You want to write fast, reliable unit tests, but every attempt to mock or patch pieces of the code leaves you in a tangled mess of complexity.
Tests are brittle, dependencies are hard or impossible to mock, and the test suite feels more like a maze than a safety net.
Sound familiar?
Are you a python backend developer looking to improve your TDD (Test Driven Development) skills?
Or perhaps you heard or seen a colleague usepytest conftest in a PR and don’t understand why or how they used it?
Well, you’ve come to the right place.
So you’re tasked with building a service that talks to external REST API.
You use the Requests or similar library, whip up some GET or POST methods and voila! All done.
Easy peasy, right?
Well not so. If you’re doing it for a hobby or quick side project then yes.
But as a professional developer, you know that you’ve to account for all edge cases.
The challenge when dealing with external APIs is that the behaviour is outside your control.
Schema or payload changes, new error codes, and updated speed caps are some problems that may plague you.