The test summary of pytest is good when you develop your application. But when you want to share these results with others, the lack of details is a problem. Let us look how we can create a more detailed report that we can share.
Code coverage tools are a great help to find code that is not yet covered by your tests. Let us look how we can find those spots with pytest.
Parametrised tests are a great help to create many test cases without the need to write many tests. Let us look how they work in pytest.
The bigger our test suite gets, the longer it takes to run all tests. With markers we get a nice way to tell pytest which test it should run and which not.
While built-in fixtures are a great help, they cannot address the specific needs of our applications. It is now time to have a closer look on how to create our own fixtures.
Fixtures are a powerful feature in pytest. You can write your own fixtures as a replacement for setup and teardown methods or use the built-in ones to access common functionality. This post has a closer look to the fixtures that come directly with pytest and shows you how to use them.
I prefer code that throws an exception as soon as it detects an unrecoverable situation. This is annoying but a lot less troublesome as when those errors go unnoticed to production. How can we test if our code throws the expected exceptions?
While trying to get a better understanding of pytest fixtures, I noticed a little problem: I could not see the output of the print() statements in my code. Let’s look why this happens and how we can change it.
Flask is a great framework, but before I continue with more elaborate parts I need to make sure that the code I wrote until now keeps working. Let’s look how we can test our code in Python.