Pytest With Eric

Almost every backend system uses a database today. After all, you need to persist system and user information.

But with that comes a challenge, your code needs to be able to efficiently read and write from a database. And it’s your job to thoroughly test it.

Databases are capable of smoothly handling read/writes, transactions and rollbacks.

So how do you test your interactions with the database?

How do you leverage the inbuilt database features to write robust I/O operations?

What about handling errors, rollbacks, transactions or network failures? Can you test for these?

Have you ever spent more time fiddling with test settings than actually writing tests?

Maybe you’ve been through the Pytest docs and seen a bunch of config (short for Configuration) files like pytest.ini, tox.ini, pyproject.toml, and setup.cfg and wondered what they are and how to use them?

Or perhaps you’re familiar with these files but did you know you can also define Pytest config in files like pyproject.toml and setup.cfg?

Say you’re working on a large test suite with a bunch of tests, each with its own set of requirements and dependencies, across different environments.

You want to run initialization commands in different environments, set up global variables, maybe slack notifications or ping an external API via a webhook to say your tests have begun.

How do you do this in Pytest? How do you tune Pytest to automatically execute tasks before running your tests?

After all you don’t want to write another script to do this. That’s just more code to maintain and more things to go wrong.

Imagine this, you’ve just joined a company and your first task is to optimise the existing test suite and improve the CI/CD run time.

Or maybe you’re a veteran Python developer and with success, your test suite has grown substantially to 1000 tests, maybe 2000 tests?

Now it’s getting out of control and each run takes 5 mins or more. CI/CD Pipelines cost a small fortune.

You’re testing backend APIs, data ETL processes, user authentication, disk writes and so on.

How do you optimize test run time? Where do you start?

With time-dependent code, a key challenge arises in testing it across various time and dates.

Consider a scenario where you’re working on a global transaction application. This application involves several time-dependent activities such as recording transaction time, date, the timezone of the transaction, and more.

How do you ensure your application functions correctly when a transaction occurs outside your country?

One approach might be to manually adjust the time, date, and timezone of your system. However, this method is non-deterministic, time-consuming, and impractical for running individual tests.

So, what’s the solution?

With Pytest, one of the tricker aspects can be understanding and controlling the standard output (stdout) and standard error (stderr).

Often, during testing, your code generates output or errors that are directed to the console.

This can lead to cluttered and obscure test outputs, making it challenging to decipher test results and debug effectively.

So how do you control what’s shown on the console and make your tests easier to debug?

You often face daunting challenges in Python - writing robust tests, managing multiple testing environments, and handling complex dependencies.

These hurdles can turn even the most straightforward project into a labyrinth of complexities.

How do you ensure your code stands the test of time and technology?

How do you maintain consistency across various environments?

And how do you streamline your project’s dependencies without getting lost in a web of version conflicts?

You may have come across the commands pytest and python -m pytest but find yourself puzzled about their differences.

Maybe you’ve seen your colleagues use either command interchangeably, and you’re wondering if they are the same.

Well, you’re not alone! It’s time to shed light on this mystery!

Releasing software without testing is like flying a plane without a maintenance check.

Testing is a safety net that helps make sure your code works well, uncovers bugs and keeps the code in good shape over its lifetime.

When developing with Python, you can use the built-in testing library called PyUnit (Unittest).

However, there are other popular and highly equipped Python testing frameworks such as Pytest, Nosetest, Doctest, and Robot - which arguably may even be better than the built-in one.

Now given so many options, how do you choose which Python testing framework to use in your application? How do you balance the trade-offs between ease of use, features and performance?

In software development, the importance of unit testing cannot be overstated.

A poorly constructed test suite can lead to a fragile codebase, hidden bugs, and hours wasted in debugging.

Not to mention hard to maintain, extend, redundant, non-deterministic and no proper coverage. So how do you deal with the complexities of crafting effective unit tests?

How do you ensure your code works as expected? What’s the difference between good and great software?