Making assertNumQueries more useful by printing the list of queries executed on failure

268 views
Skip to first unread message

Dominic Rodger

unread,
Nov 14, 2013, 1:37:43 AM11/14/13
to django-d...@googlegroups.com
Currently, when assertNumQueries fails, the output is perhaps less helpful than it might be:

Traceback (most recent call last):
  File "/home/dom/.virtualenvs/kanisa/src/kanisa/kanisa/tests/views/public.py", line 31, in test_kanisa_root_view
  File "/home/dom/.virtualenvs/kanisa/src/kanisa/.tox/py27-1.5.X/local/lib/python2.7/site-packages/django/test/testcases.py", line 195, in __exit__
    executed, self.num
AssertionError: 5 queries executed, 99 expected

When an assertNumQueries check fails, the first thing I (and I'd guess everyone else too) want to know is what queries ran, so it'd be awesome if an assertNumQueries failure printed the list of queries. Charlie Denton has a blog post describing how he does this (http://meshy.co.uk/posts/debugging-assertnumqueries-tests/), but I'd like to see this included in Django itself - since it seems generally helpful.

I'm very happy to work on this and provide a patch (and a ticket), I just wanted to solicit some feedback before I did too much work on it, in case I'm missing a reason why this hasn't already been done (I appreciate this can be done outside of Django, but I think its of sufficiently general utility to warrant being in core).

Dom

Michael Manfre

unread,
Nov 14, 2013, 9:21:52 AM11/14/13
to django-d...@googlegroups.com
Most tests written with assertNumQueries are fundamentally broken because they never check the SQL and assume that the executed queries are the ones the developer intended. I've been battling assertNumQueries for several years trying to get django-mssql to pass the full Django test suite. The current message is perfectly concise. Dumping the SQL would add a lot of noise.

Regards,
Michael Manfre



--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20327acd-1354-49dc-a5e0-16c4e7e6ee99%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

gavi...@gmail.com

unread,
Nov 15, 2013, 12:38:37 PM11/15/13
to django-d...@googlegroups.com
Every time I get a failure on one of these types of tests I go in and edit the code to print out the queries that were executed. There's no way to troubleshoot the problem without know the queries.

Aymeric Augustin

unread,
Nov 15, 2013, 3:28:09 PM11/15/13
to django-d...@googlegroups.com
On 15 nov. 2013, at 18:38, gavi...@gmail.com wrote:

Every time I get a failure on one of these types of tests I go in and edit the code to print out the queries that were executed. There's no way to troubleshoot the problem without know the queries.

I have also typed `from django.db import connection; print(connection.queries)` countless times.

We can debate whether assertNumQueries is a good practice — and with what I know of Django’s source code, I don’t doubt it’s an issue for third-party backends. Regardless I support making the failure message more useful.

— 
Aymeric.

Dominic Rodger

unread,
Nov 18, 2013, 2:58:54 PM11/18/13
to django-d...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages