Pytest With Eric

As a good developer, how do you ensure your code always works as expected?

Perhaps your boss asks, “have you tested all conditions and use cases?”

One of the most beautiful bits of programming is its deterministic nature. We tell a machine what to do, and it does the same thing—every single time.

But let’s be realistic, sometimes the real world (particularly Users) use your application in ways that you never could have predicted. Expecting it to work just fine.

How do you engineer or account for this?

You may have noticed that a lot of companies have recently gone serverless with their micro-services.

Using AWS Lambda, Google Cloud Functions, Azure or other alternatives.

The benefits and ease of complexity these technologies offer are immense — no servers to manage to auto-scaling up to 10k requests/second with AWS API Gateway.

I don’t have to convince you of the benefits of serverless but just in case here’s an interesting article to help you decide if your company should go serverless.

While serverless is brilliant, it’s quite challenging for developers to fully test and validate our code in the Cloud Ecosystem locally.

When writing Python code, you’ve probably used Environment Variables, at some point.

Whether in serverless lambda functions or stateful deployed apps.

Environment Variables are variables whose state is passed to the code or script at runtime.

Or variables whose state doesn’t change for execution (e.g. related to the system, user or network).

Although the best practices point to maintaining stateless code at all times, this is often not always possible.

Imagine deploying your code to a server and finding out it doesn’t work.

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?

Have you heard of monkeypatch but have no idea what it means?

Or maybe you’ve even seen it in your company’s code base and wondered why your colleagues use it.

Rather than go through complex documentation or a bunch of Stack Overflow posts, let’s understand what is monkeypatching at a high level and when and how we can use it to improve Unit Testing.

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.