If you’re a developer using TDD (test-driven development), you’re familiar with the importance of Unit Tests.
Perhaps you want to test several sets of input data and edge cases. Imagine writing a unit test for each of the infinite inputs.
Fortunately, there’s a better way.
As a Python developer, you may face challenges when executing tests, especially with complex directory structures.
Perhaps you faced a ModuleNotFoundError or ImportErrorwhen running your tests and wondering why Pytest cannot import the modules.
Software testing is critical to your development process, ensuring your code works as expected.
As Python continues to gain popularity as a backend and scripting language, choosing the right testing framework becomes increasingly important.
Two prominent options in the Python ecosystem are Unittest and Pytest. Both frameworks provide powerful capabilities for writing and executing tests but differ in approach, features, and community support.
In this article, we delve into the comparison between Unittest vs Pytest, shedding light on their strengths, weaknesses, and distinctive features.
While developing software, keeping track of events is crucial.
Logging helps you understand the execution flow of your code, to help catch bugs when they happen.
Although Pytest is great testing framework, it doesn’t automatically display the output of print statements or logs, which can be a problem when trying to debug failing tests or understanding flow.
So how do you go about logging and viewing events during Testing?
Can you override the default logging behavior set in the source code, just for testing?
What if you want to output logs to a file instead of the console?
As software engineers, handling errors is an important part of code development.
How often do users behave unexpectedly? More often than not. In most respect, people, systems and the Universe are random.
Maybe your code expects user input or takes data from a received packet and transforms it, perhaps performing complex calculations.
Network delays, even reordering or corrupted data. Whatever be it, it’s good to plan for the worst.
Javascript Object Notation (JSON) is arguably one of the most popular data exchange formats over the web.
Web services use serialisation to convert data from low-level data structures to JSON format that allows receiving services to easily deserialise it.
When writing Unit tests the need for testing JSON input and outputs is one of high importance.
Test data, API Responses and sometimes even config files are defined in JSON which makes it necessary to understand how to read and write to it, using Pytest.
When writing unit tests, it’s hard to consider all possible edge cases and validate that your code works correctly.
This is sometimes caught in production and a quick and speedy patch needs to be deployed. Only for a new bug to emerge later.
There will always be cases you didn’t consider, making this an ongoing maintenance job. Unit testing solves only some of these issues.
There are several frameworks for building robust and scalable Rest APIs with Python.
FastAPI, Flask and Django are the most popular, reliable and easy to use.
However, building APIs is incomplete without thorough testing.
Unit tests and Integration tests are necessary to ensure your API works for client use cases.
Most of these frameworks come with inbuilt Unittest integration, but writing and maintaining test classes can be cumbersome.
Do you find yourself with lots of boilerplate code when writing unit tests?
Monotonous code like database setup, teardown, API clients or test data can be painful to replicate across 10s or 100s of unit tests.
When writing tests, it’s often necessary to set up some initial state before running the actual test code.
This setup can be time-consuming to write, especially when there are multiple tests that require the same steps.
Continuous Integration (CI) is an essential practice in software development. It ensures you release small and quick.
Unit and Integration Testing form a vital piece of this CI/CD Pipeline. After all, what good is untested code?
But, does the thought of setting up and maintaining a CI/CD server like Jenkins, Ansible or Code Commit cause you stress?
Complex software is made up of several moving parts - Rest APIs, Databases, Cloud services, etc.
However, when writing unit tests, you’re often interested in testing a specific part of your code, not the entire system.
So how do you test your code when it depends on external services? Do you call the REST API or connect to the database in your unit tests?
APIs form the backbone of your backend operations.
Every software you interact with, from mobile to web apps, uses APIs to bridge the gap between frontend and backend.
Given it’s immense importance, testing your APIs is as crucial as building them. After all, if your API doesn’t work as expected, your entire application may be rendered useless.
Not to mention upsetting your users and clients.
FastAPI is an amazing framework for building APIs in Python.
But how do you test your FastAPI APIs? Do you test each endpoint? What about the payloads and responses?
How do you make sure your API returns helpful responses in the case of client or server errors? Should you test against real data or mock it?
Testing is an important part of the software development lifecycle (SDLC).
It helps ensure that your application is reliable, stable, and less prone to bugs (nobody is 100% immune).
Pytest is a popular testing framework to help you write and run tests for Python.
Testing helps identify bugs and errors in the software before its released to end users.
This helps prevent costly and damaging consequences.
Testing is a critical component of software development, and Pytest is one of the most popular testing frameworks out there.
It provides a powerful and flexible testing environment, allowing you to write concise, maintainable and easy-to-understand tests.
One of the beautiful things about Pytest is that it can be easily extended using plugins, which provide additional functionality and make it even easier to write and maintain your unit tests.
Staying up-to-date on pytest CLI commands can be painful.
When running tests via the console you have to remember to log the output, runtime environment variables, set timeouts, coverage, parallel executions, requirements and many others.
Programmers are good at logic, not remembering things.
That’s why we made config files. They let you specify the settings once and move on with writing your tests.
So how do you specify config in Pytest?
Imagine waking up to find your daily Unit and Integration Tests have taken ages to run or are stuck in a loop?
This happens more often than you think and for any reason — slow networks, external dependencies, resource allocation issues.
Whether you’re developing code locally or running Unit Tests as part of a CI/CD pipeline, it’s important to keep tests lightweight and fast.
An interesting concept to take note of is timeout . This means exactly what the name says — the code times out if it takes longer than x units of time.
Remember your test suite needs to be fast, timeouts are a last resort, not an expected failure mode.
Good coding practices rarely result in a timeout. Keeping that in mind, if you still wish to use timeouts, pytest timeout is an interesting feature.
Have you had to ship code without fully functional Unit Tests?
In an ideal world, you have all the time in the world to write thorough Unit and Integration tests.
But the real world wants features and bug fixes, like yesterday. This presents a challenge.
Fortunately, can “skip” or “fail” tests that are related to an upcoming feature or bug-fix and not yet ready.
Or perhaps you don’t want to run some tests every single time (e.g. connection to an external DB or API).
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 likely used environment variables to pass configuration or other data to your code at runtime.
Specifying environment variables in Python is easy, but when it comes to testing, things can get a bit tricky.
You need to understand variable preference, how to override them, and how to ensure your tests are isolated from the local runtime environment.
So how do you define environment variables in Pytest? Should you use a .env file, fixtures, specify them for each test?