Django under the hood: testing - Ana Balica¶

Running tests¶

Now on to what happens under the hood when you run the tests.

• Set up the main test runner.

• setup_test_environment() This sets up a locmem email backend. Translations are deactivated.

• build_suite(): collect all the tests. The heavy lifting is done by python’s unittest framework. Django adds some functionality, like tags.

• setup_databases()

• run_suite()

• teardown_databases()

• teardown_test_environment()

• suite_result(). Return the tests results.

Test classes¶

• SimpleTestCase. Very fast, it doesn’t interact with the database. It does have access to the test client.

• TransactionTestCase. Slow. It hits the database and does (necessary) transaction management to isolate the tests.

• TestCase. Faster than TransactionTestCase.

• LiveServerTestCase: launches a live http server in a separate test. Slow.

• StaticLiveServerTestCase. Special version of the above.

(Note TODO for myself: investigate them further, I can probably speed up my tests by using a separate testcase!)

Quality¶

Django provides test functionality, but…. how do we write high quality tests? There are some tools to help us.

• Use FactoryBoy. It replaces fixtures by easily creating model objects. It uses Faker to provide nice random data (person names, company names, email adresses).

• Hypothesis: property based testing for python. This will run tests multiple times with random data to try and find corner cases. There is a django add-on for it.

• Coverage testing. It is currently 76% for django. High coverage doesn’t mean high quality. She thinks it is a deceptive metric.

  (Personal note: I dislike this reasoning. Everybody (=several of my colleages) tend to say “high coverage doesn’t mean a thing”. Coverage metrics are discouraged when you say it like this. But, isn’t it obvious that a low coverage rate indicates bad quality tests? As most of the code isn’t tested? Yes, you cannot say tests are high quality if the coverage is high, but you can say the tests aren’t good enough if the coverage is low. So why is code coverage bad as a metric?)

• Read the django tutorial on testing! This is a good explanation. Django tries to improve your code quality by making it as easy as possible for you to write tests. https://docs.djangoproject.com/en/stable/intro/tutorial05/

Improve test speed¶

Test speed is important. The quicker, the more often you run it.

• Use MD5Passwordhasher in testing. Django does it.

• Consider in-memory sqlite3.

• Have more SimpleTestCase.

• Use setUpTestCase() instead of setUp()

• Be vigilant of what gets created in setUp()

• Don’t save model objects if not needed. Is an in-memory model enough? So instead of Robot.objects.create(), use Robot().

• Isolate the fast unit tests from the rests of the test. For instance by using SimpleTestCase. You can run those tests separate from your functional tests.

  For instance, you can run the fast tests very often during coding. When everything’s OK, you run all tests together.

Photo explanation: my son testing his strength by throwing a switch in an old signal box