12đź‘Ť
Additionally this series of articles so far has some good advice on testing django apps:
http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/
My only criticism of the answer would be to not store everything in the tests.py
file, but do as the article suggest. Create a tests
directory and turn it in to a module by adding an __init__.py
file and importing all your test cases there. eg from myapp.tests.views import *
. But definitely sound advice. Gotta walk before you can run… tests
! See what I did there?
37đź‘Ť
-
Stop coding.
-
Write the tests for the things your application is supposed to do.
First, use the built-in Django testing. Write model tests as TestCase classes inside your models.py.
Do that now. Before reading any further. Add django.test.TestCase
classes right now that create, modify and retrieve model objects. Be sure you have a test method for each property, attribute, or extra method you defined.
I’ll wait until you’ve finished that.
Model tests complete? Good.
Now create a tests.py file in each application. Every single one. All empty.
In each tests.py file create django.test.TestCase
classes for each Form.
Do it now. Create good and bad forms. Create forms with each individual field validation problem.
Don’t create all possible permutations of bad data. Just one test case for each individual validation rule.
Do that now. Before reading any further. Add django.test.TestCase
classes to tests.py for each Form.
I’ll wait until you’ve finished that.
Now, you have to test each view function. They also go in the tests.py file. Each view function has at least two test cases, perhaps more, depending on the various decorators you’re using.
If a view function requires a login, you have two cases: logged in and not logged in.
If a view function requires a permission, you have at least three cases: not logged in, logged in as the wrong user, logged in as the right user.
For now, you just need to be sure that the view function did something and returns the correct HTML template with any piece of correct data. Don’t go crazy. You just want to be sure all view functions actually return an expected page. Nothing more.
Do that now. Before reading any further. Add django.test.TestCase
classes to tests.py for each view function.
I’ll wait until you’ve finished that.
Those are the tests you should write first before writing any application code.
This will give you a testing baseline that confirms that your application will minimall sort-of run.
One you have that finished, you can start to consider unit tests that reflect the real purpose and value behind your application.
- [Django]-Filtering dropdown values in django admin
- [Django]-Missing Table When Running Django Unittest with Sqlite3
- [Django]-Filtering using viewsets in django rest framework
7đź‘Ť
I’m assuming that you are done with Testing Django Applications. With the right set of helper tools you should be fine with the default unit testing using Django test framework.
To get you started with measuring coverage you might want to look into coverage standalone to figure out what you have tested.
Once installed, you can do something like this:
$ coverage run manage.py test *yourapp*
It will create .coverage
file for you. You can format the data from this file with
$ coverage report
to get a full list on testing coverage (including code from other python libraries).
You can easily coverage report --omit path
modules that start with particular paths. Additionally you would be able to see the lines that were not executed during the test run with -m
option.
Also, I think there is a django_coverage
Django application that integrates coverage
into testing for Django project. It makes nice HTML coverage reports for you.
Now there are other tools like twill, etc. to address specific needs (like javascript testing).
Also, if you want to go through the detailed baby steps of setting up vanilla testing under Django, you may want to read “Django 1.1 Testing and Debugging” (lookup on Amazon).
- [Django]-Django REST Framework : "This field is required." with required=False and unique_together
- [Django]-Extend base.html problem
- [Django]-How to merge consecutive database migrations in django 1.9+?