Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#14774 closed (fixed)

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

Reported by: Luke Plant Owned by: Jonas Obrist
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: no UI/UX: no

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 Jonas Obrist 14 years ago.
tests for 14774 (they're failing at the moment)
14774.diff (5.5 KB ) - added by Jonas Obrist 14 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 by Alex Gaynor, 14 years ago

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 by Alex Gaynor, 14 years ago

Component: UncategorizedTesting framework
milestone: 1.3
Triage Stage: UnreviewedAccepted

comment:3 by anonymous, 14 years ago

Cc: chris.peplin@… added

by Jonas Obrist, 14 years ago

Attachment: 14774.tests.diff added

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

comment:4 by Jonas Obrist, 14 years ago

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?

in reply to:  4 comment:5 by Luke Plant, 14 years ago

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 by Russell Keith-Magee, 14 years ago

Keywords: blocker added

by Jonas Obrist, 14 years ago

Attachment: 14774.diff added

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

comment:7 by Jonas Obrist, 14 years ago

Has patch: set
Owner: changed from nobody to Jonas Obrist

comment:8 by Alex Gaynor, 14 years ago

Resolution: fixed
Status: newclosed

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

comment:9 by Jacob, 13 years ago

milestone: 1.3

Milestone 1.3 deleted

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