Cyber Monday discount for Speed Up Your Django Tests
Earlier this week I tweeted about my two part offer on my book Speed Up Your Django Tests for this year’s Cyber Monday.
Earlier this week I tweeted about my two part offer on my book Speed Up Your Django Tests for this year’s Cyber Monday.
I previously covered writing a Django application in a single file, for both synchronous and asynchronous use cases. This post covers the angle of creating a REST API using Django in a single file.
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.
Last week, I released a new Django package, django-read-only. It provides a read-only mode for Django’s database layer.
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.
You run your tests with manage.py test. You know what happens inside your tests, since you write them. But how does the test runner work to execute them, and put the dots, Es, and Fs on your screen?
There are a few mini sites out there with “bonus” Django documentation. Here’s a list of the best ones I know of.
The N+1 Queries Problem is a perennial database performance issue. It affects many ORMs and custom SQL code, and Django’s ORM is not immune either.
In Python, Lambda functions are rare compared to “normal” functions, and occasionally misunderstood or overused.
Last week I covered Django’s database instrumentation, and making a wrapper that’s always installed. Here’s a different use case that I encountered last year on a project.
Here’s a small warning I’ve come across a couple of times, and how to fix it with a niche pytest feature.
If you’ve read the Django documentation for Model.Meta.index_together recently, you may have noticed this note:
Since version 2.0, Django has provided a hook for installing database instrumentation wrapper functions. These functions are like middleware for database queries, allowing you to inspect and rewrite SQL before it is sent to the database. There are many use cases, for example:
Django’s test command takes the --parallel flag to activate parallel testing. Unfortunately, this has never worked on Windows, and with Python 3.8 it has stopped working on macOS.
Here’s a conversation I had earlier with the late Ernest Hemingway:
Your Django project may use some packages that add instrumentation, for example:
Since I launched my book Speed Up Your Django Tests I’ve had a number of questions about possible discounts. I want to make my book affordable for all and understand that $49 is a high price tag for some. The Django community is global and I want to share knowledge with Djangonauts everywhere.
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:
The /.well-known/ URL path prefix is a reserved name space for serving particular static files used by other systems that might interact with your site. It was established by RFC 5785 and updated in RFC 8615. The IANA maintains a list of possible files in the Well Known URIs registry, but others are in wide use without official registration (yet?).
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: