(All tags.)
TestCase from using setUp() to setUpTestData()Django’s TestCase class provides the setUpTestData() hook for creating your test data. It is faster than using the unittest setUp() hook because it creates the test data only once per test case, rather than per test.
I wrote my library time-machine last year as a way to speed up tests that need to accurately mock the current time.
For all my linting needs these days I use the pre-commit framework. It has integrations with every tool I want to use, and uses Git’s hooks to prevent non-passing code from ever being committed.
I recently optimized a client project’s test suite, and in the process found a test whose runtime had crept up ever since it had been written. The problematic test exercised an import process from a fixed past date until the current day. The test’s runtime therefore grew every day, until it reached over a minute.
In all current releases of the popular WSGI server gunicorn, the Server header reports the complete version of gunicorn. I spotted this on my new project DB Buddy. For example, with httpie to check the response headers:
If you’re testing Python code that relies on the current date or time, you will probably want to mock time to test different scenarios. For example, what happens when you run a certain piece of code on February 29? (A common source of bugs.)
Earlier this week I tweeted about my two part offer on my book Speed Up Your Django Tests for this year’s Cyber Monday.
Sometimes tests need to change environment variables. This is fairly straightforward in pytest, thanks to os.environ quacking like a dict, and the mock.patch.dict decorator/context manager.
Sometimes, tests need to change environment variables. This is straightforward in tests using Python’s unittest, thanks to os.environ quacking like a dict, and the mock.patch.dict decorator/context manager.
When we write custom management commands, it’s easy to write integration tests for them with call_command(). This allows us to invoke the management command as it runs under manage.py, and retrieve the return code, standard output, and standard error. It’s great, but has some overhead, making our tests slower than necessary. If we have logic separated out of the command’s handle() method, it improves both readability and testability, as we can unit test it separately.
In Python, Lambda functions are rare compared to “normal” functions, and occasionally misunderstood or overused.
A Python decorator wraps a target function with another wrapper function. This wrapper function can add any behavior you might want. For example, it can track execution times, redefine how the wrapped function runs, or modify return values.
Imagine we are installing the third party package django-cors-headers, which I maintain. Step one in its installation process is to install the package, so we run the command:
By default, Python buffers output to standard output (stdout) and standard error (stderr). This means that output from your code might not show up immediately, making debugging harder.
SyntaxWarning: list indices must be integers or slicesTake this code, which we want to return a list of two breakfast orders:
SyntaxWarning: assertion is always trueTake this code:
SyntaxWarning: '<type>' object is not subscriptableTake this code:
SyntaxWarning: '<type>' object is not callableTake this code, which we want to return a list of shopping items with desired quantities:
Django’s test client is really useful for writing integration tests for your project. It’s great because it has a simple API for testing your application similarly to how a web browser would interact with it. Unfortunately it can be slow, because each call creates a request, passes it through all your middleware, view, maybe a template, then the response comes back through the same layers.
This is a test anti-pattern I’ve seen creep in on many Django test suites. I know of several large projects where it became a major undertaking to undo it. The good news is it’s easy to avoid adding it when you first write your tests. 🙂
Whilst writing Speed Up Your Django Tests, I wanted to add a section about mocking the current time. I knew of two libraries for such mocking, but I found it hard to pick one to recommend due to the trade-offs in each. So I delayed adding that section and shaved a rather large yak by writing a third library.
Django’s transaction.on_commit() hook is useful for running tasks that rely on changes in the current database transaction. The database connection enqueues callback functions passed to on_commit, and executes the callbacks after the current transaction commits. If the transaction is rolled back, the callbacks are discarded. This means they act if-and-when the final version of the data is visible to other database connections.
My previously announced book “Speed Up Your Django Tests” is out now on Gumroad. I’ve been writing since the 3rd March, so it’s quite a relief to have launched it.
It’s occasionally useful to be able to tell which Django manage.py command is being run, in a code path that otherwise has no way of telling. For example, in Speed Up Your Django Tests, I describe how to modify manage.py to default use a test settings file when the test command is run.
At the start of March I started writing a blog post called “How to Speed Up Your Django Tests”. Before I knew it, the outline alone was 4,000 words! I realized writing it up would be a major undertaking. As lockdown arrived, I found the time to write it all up.