Testing

Last Friday, Caktus set aside client projects for our regular quarterly ShipIt Day. From gerrymandered districts to RPython and meetup planning, the team started off 2017 with another great ShipIt.

Part two of six in our annual PyCon Must-See Series, a weekly highlight of talks our staff especially loved at PyCon. With so many fantastic talks, it’s hard to know where to start, so here’s our short list.

Editor's note: This post was originally published in February 2016 and was updated in August 2017 to incorporate improvements suggested by our readers. It has also been tested for compatibility as of the Django 1.11 release.

I had the opportunity to give a webcast for O’Reilly Media during which I encountered a presenter’s nightmare: a broken demo. Worse than that it was a test failure in a presentation about testing. Is there any way to salvage such an epic failure?

Technical Director Mark Lavin will be hosting a free O’Reilly webinar today at 4PM EST or 1PM PT on Testing Client-Side Applications with Django. Mark says testing is one of the most popular question topics he receives. It’s also a topic near and dear to Caktus’ quality-loving heart. Mark’s last webinar garnered more than 500 viewers, so sign up quick!

From time to time we inherit code bases running outdated versions of Django and part of our work is to get them running a stable and secure version. In the past year we've done upgrades from versions as old as 1.0 and we've learned a few lessons along the way.

Colin Copeland, Managing Member at Caktus, has wrapped up work, supported by UNICEF, as the Community Coordinator for the open source RapidSMS project. RapidSMS is a text messaging application development library built on top of the Django web framework. It creates a SMS provider agnostic way of sending and receiving text messages. RapidSMS has been used widely in the mobile health field, in particular in areas where internet access cannot be taken for granted and cell phones are the best communication tool available. This has included projects initiated by UNICEF country offices in Ethiopia, Madagascar, Malawi, Rwanda, Uganda, Zambia, and Zimbabwe.

We are always looking for ways to make our tests run faster. That means writing tests which don't preform I/O (DB reads/writes, disk reads/writes) when possible. Django has a collection of TestCase subclasses for different use cases. The common TestCase handles the fixture loading and the creation the of TestClient. It uses the database transactions to ensure that the database state is reset for every test. That is it wraps each test in a transaction and rolls it back once the test is over. Any transaction management inside the test becomes a no-op. Since [TestCase]{.title-ref}[ overrides the transaction facilities, if you need to test the transactional behavior of a piece of code you can instead use ]{.title-ref}[TransactionTestCase]{.title-ref}[. ]{.title-ref}[TransactionTestCase]{.title-ref}` resets the database after the test runs by truncating all tables which is much slower than rolling back the transaction particularly if you have a large number of tables.

When testing a Django application you often need to populate the test database with some sample data. The standard Django TestCase has support for fixture loading but there are a number of problems with using fixtures:

If you’ve ever written a test for a view or model with associated uploaded files you might have noticed a small problem with those files hanging around after the tests are complete. Since version 1.3, Django won’t delete the files associated with your model instances when they are deleted. Some work-arounds for this issue involve writing a custom delete for your model or using a post_delete signal handler. But even with those in place the files would not be deleted during tests because the model instances are not explicitly deleted at the end of the test case. Instead, Django simply rolls back the transaction and the delete method is never called nor are the signals fired. This can be quite an annoyance when running the tests repeatedly and watching your MEDIA_ROOT (or worse your S3 bucket) fill up with garbage data. More than annoyance, this introduces something you always want to avoid in unittests: global state.