Something that is untested is broken, and that is why am writing on Testing flask applications using Pytest , although the origin of this quote is unknown and while it is not entirely correct, it is also not far from the truth. Untested applications make it hard to improve existing code and developers of untested applications tend to become pretty paranoid. If an application has automated tests, you can safely make changes and instantly know if anything breaks.
Flask provides a way to test your application by exposing the Werkzeug test
Client and handling the context locals for you. You can then use that with your favourite testing solution.
In this documentation we will use the pytest package as the base framework for our tests. You can install it with
pip, like so:
The Testing Skeleton
We begin by adding a tests directory under the application root. Then create a Python file to store our tests (
test_flaskr.py). When we format the filename like
test_*.py, it will be auto-discoverable by pytest.
Next, we create a pytest fixture called
client() that configures the application for testing and initializes a new database.:
import os import tempfile import pytest from flaskr import flaskr @pytest.fixture def client(): db_fd, flaskr.app.config['DATABASE'] = tempfile.mkstemp() flaskr.app.config['TESTING'] = True client = flaskr.app.test_client() with flaskr.app.app_context(): flaskr.init_db() yield client os.close(db_fd) os.unlink(flaskr.app.config['DATABASE'])
This client fixture will be called by each individual test. It gives us a simple interface to the application, where we can trigger test requests to the application. The client will also keep track of cookies for us.
TESTINGconfig flag is activated. What this does is disable error catching during request handling, so that you get better error reports when performing test requests against the application.
Because SQLite3 is filesystem-based, we can easily use the
tempfile module to create a temporary database and initialize it. The
mkstemp() function does two things for us: it returns a low-level file handle and a random file name, the latter we use as database name. We just have to keep the db_fd around so that we can use the
os.close() function to close the file.
To delete the database after the test, the fixture closes the file and removes it from the filesystem.
If we now run the test suite, we should see the following output:
$ pytest ================ test session starts ================ rootdir: ./flask/examples/flaskr, inifile: setup.cfg collected 0 items =========== no tests ran in 0.07 seconds ============
Even though it did not run any actual tests, we already know that our
flaskr application is syntactically valid, otherwise the import would have died with an exception.
The First Test
Now it’s time to start testing the functionality of the application. Let’s check that the application shows “No entries here so far” if we access the root of the application (
/). To do this, we add a new test function to
test_flaskr.py, like this:
def test_empty_db(client): """Start with a blank database.""" rv = client.get('/') assert b'No entries here so far' in rv.data
Notice that our test functions begin with the word test; this allows pytest to automatically identify the function as a test to run.
client.get we can send an HTTP
GET request to the application with the given path. The return value will be a
response_class object. We can now use the
data attribute to inspect the return value (as string) from the application. In this case, we ensure that
'No entries here so far' is part of the output.
Run it again and you should see one passing test:
$ pytest -v ================ test session starts ================ rootdir: ./flask/examples/flaskr, inifile: setup.cfg collected 1 items tests/test_flaskr.py::test_empty_db PASSED ============= 1 passed in 0.10 seconds ==============
Logging In and Out
The majority of the functionality of our application is only available for the administrative user, so we need a way to log our test client in and out of the application. To do this, we fire some requests to the login and logout pages with the required form data (username and password). And because the login and logout pages redirect, we tell the client to follow_redirects.
Add the following two functions to your
def login(client, username, password): return client.post('/login', data=dict( username=username, password=password ), follow_redirects=True) def logout(client): return client.get('/logout', follow_redirects=True)
Now we can easily test that logging in and out works and that it fails with invalid credentials. Add this new test function:
def test_login_logout(client): """Make sure login and logout works.""" rv = login(client, flaskr.app.config['USERNAME'], flaskr.app.config['PASSWORD']) assert b'You were logged in' in rv.data rv = logout(client) assert b'You were logged out' in rv.data rv = login(client, flaskr.app.config['USERNAME'] + 'x', flaskr.app.config['PASSWORD']) assert b'Invalid username' in rv.data rv = login(client, flaskr.app.config['USERNAME'], flaskr.app.config['PASSWORD'] + 'x') assert b'Invalid password' in rv.data
Test Adding Messages
We should also test that adding messages works. Add a new test function like this:
def test_messages(client): """Test that messages work.""" login(client, flaskr.app.config['USERNAME'], flaskr.app.config['PASSWORD']) rv = client.post('/add', data=dict( title='<Hello>', text='<strong>HTML</strong> allowed here' ), follow_redirects=True) assert b'No entries here so far' not in rv.data assert b'<Hello>' in rv.data assert b'<strong>HTML</strong> allowed here' in rv.data
Here we check that HTML is allowed in the text but not in the title, which is the intended behavior.
Running that should now give us three passing tests:
$ pytest -v ================ test session starts ================ rootdir: ./flask/examples/flaskr, inifile: setup.cfg collected 3 items tests/test_flaskr.py::test_empty_db PASSED tests/test_flaskr.py::test_login_logout PASSED tests/test_flaskr.py::test_messages PASSED ============= 3 passed in 0.23 seconds ==============
Other Testing Tricks
Besides using the test client as shown above, there is also the
test_request_context() method that can be used in combination with the
with statement to activate a request context temporarily. With this you can access the
session objects like in view functions.