Testing is a sore subject for many in the software industry.

Testing is a commonly agreed upon practice that is likely the first to go when a deadline approaches.

In this post, I propose establishing an infrastructure for rapid test creation and maintenance.  I will also cover some popular testing tools and their integration with Django.

Django already promotes testing by automatically generating a test.py file when you create an app from the command line. However, there are many other testing tools and ways to structure testing then the out of the box python manage.py tests solution provided by Django. We will explore another approach alongside the above method and discuss why either might be integrated into your development process.

Here is an example of auto-generated structure:

One of the first questions you may ask is what should I even be testing? Tools such as coverage attempt to guide these type of questions. Usage is simple with both Django and pytest (a popular testing framework).

To use, install coverage and run:

– or –

After running the tests with coverage, use >> coverage report to see coverage metrics in the terminal or >> coverage html to generate an interactive html to navigate in the browser. Using tools such as coverage allow users unfamiliar with testing to target the common places testing is needed (views, custom functions, etc) and, without knowing what a smoke test even is, one can contribute to the coverage and overall stability of the app. This reduces the barrier of entry for engineers unfamiliar with testing practice.

Now that we have an idea of what we need to test, let’s talk about where to put your tests in the application. If using the Django management command, and its corresponding tests, leave the tests in their apps. This is a maintainable framework for a small Django application. If testing using pytest and other tools or if you have a large, complex application create a /tests folder, with your /apps beneath it and finally a folder with the corresponding app name at the end (for example, /accounts). Within this directory, tests for models, views, custom functions should become separate .py files. It is best to be explicit and systematic with these testing structures.

Here is an example structure:

Why do this? It makes navigating, creating, editing, and executing tests more streamlined and maintainable as development continues. These tools are only effective if used and are accessible to your development team.

My parting message is test. Just start doing it. Require it. We all fall behind and need to make cuts. However, investing the time needed to create this framework (and use these tools!) will strengthen the application and give more support for future development. Then you can go home and pat yourself on the back for establishing a more robust Django Application. The moment when all of the tediousness required to write these tests yields a fatal bug or saves your team from a damaging production launch will bring clarity to its purpose and necessity in software development.

Many are also interest in end to end (e2e) browser testing with tools like Selenium. This asserts more front end and UX than the Django tests I’ve described in this post, which are more focused on how data is managed and presented via the back-end. These are important tests as well (and something Django has support for!), but is a topic for another post.

Best of luck on your testing journey!