Faker is a test data generator we explored in the last post. Despite the large list of options to generate data, sometimes we need data in a format that Faker cannot offer. Should that happen, we can create our own data provider. Let us figure out how to do that.
If you have ever worked on a project that needed realistic test data, you know how tedious it can be to create it manually. Hardcoding names, addresses, or even phone numbers into your test suite not only clutters your code but also makes it inflexible. Thankfully, the Python Faker library comes to the rescue.
After finishing the dashboard, I hoped to quickly switch my datastore implementation to use the asynchronous methods for SQLAlchemy. Unfortunately, that was not the case. Everything needs to change, and that change must be done all at once. That includes pytest, that we need to run our tests.
To make the change more understandable, we start in this post with pytest and do the necessary work to test asynchronous methods. With that out of our way, we can next week focus on SQLAlchemy.
Last week we moved from an in-memory data store to SQLAlchemy and persist our tasks inside an SQLite database. We have two things we need to optimize, or else we end up with problems along the way.
If we do not want to keep starting our API and manually click through the endpoints to see if everything still works, we need to put a little effort into testing. Thanks to the underlying Starlette toolkit, we can test our FastAPI application in-memory and do not need a dedicated server. Let us explore how that helps us with testing our API.
Selenium is great to automate repetitive task in a web browser. We can take that concept one step further and use it to create end-to-end tests for web applications. Today we look at an approach to keep the initialisation code for Selenium in one place and use it in as many tests as we need.
After last week’s introduction to doctest it is now time to have a closer look at dynamic output and how we can test that with doctest.
Documentation is an important part of every software project – and probably the most neglected one. Nothing is worse than outdated documentation with examples that no longer work. Python has a great little helper to ensure that your documentation is up to date.
If you get bored by the dots in the pytest test-runner you may be interested in the pytest-sugar plugin. Let us look what it does and how you can get it.
The more I work with pytest, the more I like the flexibility it offers. Today I post about 3 command-line options that help me a lot and are easy to overlook.