Django test client performs integration tests. All middleware classes, resolvers, decorators and so on are tested. Just a single failure in a middleware can break all the view tests.
One technique of performing the tests was presented at DjangoCon Europe 2013. We, at Sunscrapers have decided to do it in slightly different way, which is why djet has been created.
djet makes performing unit tests for your views easier by providing
self.client, you can use
self.factory, which is an
RequestFactory with overridden shortcuts for creating requests
path is not required parameter).
Sometimes you would need middleware to be applied in order to test the view.
There is an option that helps specify which middleware should be used in
a single test or a whole test case by applying
This argument should be a list of middleware classes (e.g.
or tuples where first argument is middleware class and rest items are middleware
MiddlewareType class). In this case only indicated middleware methods
will be call.
djet also provides additional assertions via mixin classes within
djet.assertions module. They have been created to simplify common
testing scenarios and currently there is
InstanceAssertionsMixin full of useful assertions.
Remember that if you want to use assertions e.g. from
you must also add
middleware_classes required by messages to your test case.
We do not add them for you in mixin, because we believe those mixin classes shouldn’t
implicitly mess with middleware, because it would make it harder to understand
what and why exactly is happening in your tests.
Testing file uploads¶
There are three primary issues, while testing file-related code in Django
djet.files module attempts to solve all of these.
First thing - you won’t need any files put somewhere next to fixtures anymore.
create_inmemory_image are ready to use.
Those helpful functions are taken from
great blog post by Piotr Maliński
with just a few small changes.
You can also use
InMemoryStorage which deals with files being saved to disk
during tests and speed ups tests by keeping them in memory.
InMemoryStorageMixin does another great thing.
InMemoryStorage for you and also
removes all files after test
tearDown, so you will no longer see any files
crossing between tests. You can also provide any storage you want,
it should only implement
clear method which is invoked after tearDown.
InMemoryStorageMixin cannot be used with bare
you have to use
TestCase from Django or
ViewTestCase from djet.