Code

Opened 2 years ago

Closed 16 months ago

Last modified 16 months ago

#17312 closed Cleanup/optimization (fixed)

Testing examples should use django.utils.TestCase

Reported by: jcspray@… Owned by: nobody
Component: Documentation Version: master
Severity: Normal Keywords:
Cc: krw1243 Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The 'Testing Django applications page' (https://docs.djangoproject.com/en/dev/topics/testing/) gives many examples of tests using unittest2.TestCase directly rather than django.test.TestCase.

For the DB to be reset between tests it is essential to use django.test.TestCase, and that is not made at all obvious in this documentation.

  • At least: a prominent warning should be present about the fact that DB side effects are possible when using unittest2.TestCase
  • Preferably: the examples should use django.utils.TestCase since it is a safer default.

Attachments (1)

17312.diff (2.1 KB) - added by timo 16 months ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 2 years ago by krw1243

  • Cc krw1243 added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 2 years ago by ptone

  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 2 years ago by aaugustin

  • Triage Stage changed from Accepted to Design decision needed

Within Django itself, the convention is to use unittest.TestCase for tests that don't need django.test.TestCase, although I'm not entirely sure about the reason (performance?).

I'd like to see a benchmark before recommending to use django.test.TestCase unconditionally.

Last edited 2 years ago by aaugustin (previous) (diff)

comment:4 Changed 2 years ago by ptone

As the differences are already documented: https://docs.djangoproject.com/en/dev/topics/testing/#testcase

perhaps it would suffice just to have a quick note about database effects and a forward link to that section of the docs at the bottom of the introduction "writing unit tests" (just before the "writing doctests" section)

https://docs.djangoproject.com/en/dev/topics/testing/#writing-unit-tests.

Changed 16 months ago by timo

comment:5 Changed 16 months ago by timo

  • Has patch set
  • Triage Stage changed from Design decision needed to Accepted

I think a warning is definitely appropriate. In fact, the current example has database side effects.

comment:6 Changed 16 months ago by claudep

  • Triage Stage changed from Accepted to Ready for checkin

comment:7 Changed 16 months ago by Tim Graham <timograham@…>

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

In 7df03268a467a9aec9c4c574c85317a738ca33ae:

Fixed #17312 - Warned about database side effects in tests.

Thanks jcspray for the suggestion.

comment:8 Changed 16 months ago by Tim Graham <timograham@…>

In 2545dc59bf44131a1f60f7393f29f025939f3a09:

[1.5.x] Fixed #17312 - Warned about database side effects in tests.

Thanks jcspray for the suggestion.

Backport of 7df03268a467a9aec9c4c574c85317a738ca33ae from master.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.