Someone recently asked me<\/p>\n
\nWhen is a good time to get automated testing setup on a new Django project?<\/p>\n<\/blockquote>\n
The answer is \"now\". There are other good times, but now is best. In this post I'll briefly make my case for why, and show you an example of a minimal \u2026<\/p>","content":"
Someone recently asked me<\/p>\n
\nWhen is a good time to get automated testing setup on a new Django project?<\/p>\n<\/blockquote>\n
The answer is \"now\". There are other good times, but now is best. In this post I'll briefly make my case for why, and show you an example of a minimal setup of Django running tests with pytest<\/a> with fully automated continuous integration<\/a> (CI) using GitHub Actions<\/a>.<\/p>\n
As soon as you know a Django project is going to be \"serious\", then you should get it set up to run tests. So, potentially before you write any features. My approach is to get testing setup and to write a dummy test or two and then get it running in CI. This means that as soon as you start writing features then you will have everything you need to write a real test and have it run automatically on every commit.<\/p>\n
The alternate scenario is you start adding features and get swept up in that process. At some point you'll think \"hmm maybe I should write a test for this...\", but if you don't have tests and CI set up already then you're more likely to say \"nah, fuck it I'll do it later\" and not write the test. Getting pytest to work with Django on GitHub actions is pretty easy these days. Bite the bullet, it tastes better than you may expect.<\/p>\n
Or you could just not write any tests. This is fine for small personal projecs. Tests are a lot of things but they're not fun. For more serious endeavours though, not having tests will lead to riskier deployments, longer feedback loops on errors and less confidence in making big changes. Have you ever done a huge, wild refactor of a chunk of code, followed by a set of passing tests? It feels great man, that's when you're really living.<\/p>\n
The other question is: when should I run my tests? Sometimes you forget or you can't be bothered. This is where GitHub Actions (or any other CI) is very useful. You can set this service up to automatically run your tests every time<\/em> you push a commit up to GitHub.<\/p>\n
Let's go then: how do you set up Django + pytest + GitHub Actions? All the code discussed here can be found in this example GitHub repository<\/a>.<\/p>\n
Installation<\/h2>\n
Alongside Django you will need to install
pytest<\/code><\/a> andpytest-django<\/code><\/a>. These libraries are not required to run tests with Django: the official docs<\/a> show you how to use Python's unittest library instead. I like pytest better though, and I think you will too. My requirements.txt<\/a> file looks like this:<\/p>\n<\/span>django\npytest\npytest-django\n<\/code><\/pre><\/div>\n\nI don't pin my dependencies because I'm lazy: what can I say? I recommend you setup a virtual environment<\/a> and then install as follows:<\/p>\n
<\/span>pip install -r requirements.txt\n<\/code><\/pre><\/div>\n\nConfiguraton<\/h2>\n
You can configure pytest with a standard pyproject.toml<\/a> file. Here's mine<\/a>. The most important thing is to set
DJANGO_SETTINGS_MODULE<\/code><\/a> so pytest knows which settings to use. It's good to have a separate set of test settings for your project so that you can avoid, for example, accidently changing your production environment with credentials stored in settings when you run a test.<\/p>\n<\/span>[tool.pytest.ini_options]<\/span><\/span>\nDJANGO_SETTINGS_MODULE<\/span> <\/span>=<\/span> <\/span>"demo.settings"<\/span><\/span>\nfilterwarnings<\/span> <\/span>=<\/span> <\/span>[<\/span><\/span>\n <\/span>"ignore::UserWarning",<\/span><\/span>\n]<\/span><\/span>\n<\/code><\/pre><\/div>\n\nThis file should live in whichever folder you will be running
pytest<\/code> from. For the reference project, that means in the.\/app<\/code> folder alongsidemanage.py<\/code>.<\/p>\nAdding a dummy test<\/h2>\n
That's a good start. Now we can test the setup so far with a dummy test. This test does nothing: it always passes, but it verifies that all the plumbing is working. In pytest, tests are just functions that use assert statements to check things:<\/p>\n
<\/span>def<\/span> test_nothing<\/span>():<\/span>\n """A dummy test"""<\/span>\n assert<\/span> True<\/span>\n<\/code><\/pre><\/div>\n\nPytest looks for a
tests<\/code> folder in your Django apps. For example, here is the tests folder<\/a> in the reference project. So this dummy test function could live in a file namedapp\/web\/tests\/test_dummy.py<\/code>. You can add as many tests to a file as you like, or have as many test files as you like. Avoid duplicate names though!<\/p>\nRunning the tests locally<\/h2>\n
At this stage it's good to check that the dummy test works by running pytest from the command line:<\/p>\n
<\/span>pytest -vv\n<\/code><\/pre><\/div>\n\nRead
-vv<\/code> as \"very verbose\". Here are specific instructions<\/a> for anyone trying out the reference project. Hopefully that worked. You may see a folder called.pytest_cache<\/code> appear in your project. I recommend you gitignore<\/a> this.<\/p>\nNow let's add some more meaningful example tests before we move on to setting up GitHub Actions.<\/p>\n
Adding a basic view test<\/h2>\n
My reference project has a very basic view named \"goodbye\" which just returns the text \"Goodbye world\". Here it is:<\/p>\n
<\/span>def<\/span> goodbye_view<\/span>(<\/span>request<\/span>):<\/span>\n return<\/span> HttpResponse<\/span>(<\/span>f<\/span>"Goodbye world"<\/span>)<\/span>\n<\/code><\/pre><\/div>\n\nYou can test that this view returns the expected response using the Django test client<\/a>. Pytest has a handy feature called fixtures<\/a>, which is a little piece of magic where you ask for an speficic object via the test function arguments and pytest automagically provides it. In this case we add \"client\" to the function arguments to get a test client. It's a little out of scope for this post, but you can write your own fixtures too!<\/p>\n
<\/span>def<\/span> test_goodbye_view<\/span>(<\/span>client<\/span>):<\/span>\n """Test that goodbye view works"""<\/span>\n # Build the URL from the url's name<\/span>\n url<\/span> =<\/span> reverse<\/span>(<\/span>"goodbye"<\/span>)<\/span>\n # Make a GET request to the view using the test client<\/span>\n response<\/span> =<\/span> client<\/span>.<\/span>get<\/span>(<\/span>url<\/span>)<\/span>\n # Verify that the response is correct<\/span>\n assert<\/span> response<\/span>.<\/span>status_code<\/span> ==<\/span> 200<\/span>\n assert<\/span> response<\/span>.<\/span>content<\/span> ==<\/span> b<\/span>"Goodbye world"<\/span>\n<\/code><\/pre><\/div>\n\nVery nice, but you will find that you need to do a little more work to test views that include database queries.<\/p>\n
Adding a view test with database interaction<\/h2>\n