Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#14774 closed (fixed)

assertNumQueries is buggy with views and the test client if used more than once in a test

Reported by: lukeplant Owned by: ojii
Component: Testing framework Version: 1.2
Severity: Keywords: blocker
Cc: chris.peplin@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

With code like this:

with self.assertNumQueries(5):
    self.client.get("some/view/")

with self.assertNumQueries(5):
    self.client.get("some/view/")

The second one always fails, with '0' being the number of queries it calculates. (I do not have any caching enabled).

If the second client.get goes to a view that actually uses less queries than the first, then assertNumQueries calculates a negative number of queries, which seems to be the true number minus the number of queries from the last assertNumQueries. I can't quite pin down the behaviour.

I'm guessing this has to do with the way test client/request life-cycle/connections interact. I do not see this with normal queries done directly in the function.

If someone else could confirm that would be helpful.

This happens:

  • Using assertNumQueries either with the 'with' statement or passing a function in.
  • with SQLite (haven't tested with others)
  • with or without the TransactionMiddleware

Attachments (2)

14774.tests.diff (1.9 KB) - added by ojii 4 years ago.
tests for 14774 (they're failing at the moment)
14774.diff (5.5 KB) - added by ojii 4 years ago.
fixed this issue by wrapping the reset_queries signal in the assertNumQueries context

Download all attachments as: .zip

Change History (11)

comment:1 Changed 5 years ago by Alex

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Almost certainly caused by the reset_queries signal: http://code.djangoproject.com/browser/django/trunk/django/db/__init__.py#L87 . I'll think on what can be done about this, as for obvious reasons the context manager/function records the number of queries before it calls the function, and then clears it. Perhaps this function should respect use_debug_cursor or something. Again, needs thoughts.

comment:2 Changed 5 years ago by Alex

  • Component changed from Uncategorized to Testing framework
  • milestone set to 1.3
  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 4 years ago by anonymous

  • Cc chris.peplin@… added

Changed 4 years ago by ojii

tests for 14774 (they're failing at the moment)

comment:4 follow-up: Changed 4 years ago by ojii

I've added some tests but they fail with -3!=1. How would assertNumQueries think that there's negative queries? Is this an issue with my tests or an actual issue with assertNumQueries?

comment:5 in reply to: ↑ 4 Changed 4 years ago by lukeplant

Replying to ojii:

Is this an issue with my tests or an actual issue with assertNumQueries?

It's an issue with assertNumQueries - I also saw assertNumQueries thinking that a negative number of queries had occurred. The only workaround at present is to use the view functions directly, rather than using the client interface.

comment:6 Changed 4 years ago by russellm

  • Keywords blocker added

Changed 4 years ago by ojii

fixed this issue by wrapping the reset_queries signal in the assertNumQueries context

comment:7 Changed 4 years ago by ojii

  • Has patch set
  • Owner changed from nobody to ojii

comment:8 Changed 4 years ago by Alex

  • Resolution set to fixed
  • Status changed from new to closed

(In [15251]) Fixed #14774 -- the test client and assertNumQueries didn't work well together. Thanks to Jonas Obrist for the initial patch.

comment:9 Changed 4 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

Note: See TracTickets for help on using tickets.
Back to Top