Code

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#15595 closed Bug (fixed)

emphasize the importance of 'from django.test import TestCase'

Reported by: lawgon Owned by: ShawnMilo
Component: Documentation Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX:

Description

On reading the dev docs on tests one starts of with importing unittest either directly or from django.utils. The docs should clearly specify at the beginning that the optimal way is to do from django.test import TestCase as this will automatically import unittest2 as well as all the goodies.

Attachments (1)

15595_TestCase_docs.diff (1.1 KB) - added by ShawnMilo 3 years ago.
Changes at Russell's suggestion.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by MikeRamirez

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

comment:2 Changed 3 years ago by lawgon

as mike has mentioned, now django ships with import of TestCase from django.test in the sample test file in an app created by startapp. So it makes a case for putting that as default in the documentation.

comment:3 Changed 3 years ago by russellm

  • Triage Stage changed from Unreviewed to Accepted

No, it isn't a good idea to recommend django.test.TestCase unilaterally. It's a matter of picking the right tool for the job. django.test.TestCase is an extension that contains a number of extra features for testing Django views, etc. However, those extra features have a significant overhead. If you don't need a test database for testing a particular function, you shouldn't be using django.test.testCase.

That said, django.test.TestCase is introduced quite late in the testing docs -- we should probably mention it in passing during the early stages so that the existence of the class isn't lost in the noise.

comment:4 Changed 3 years ago by lukeplant

  • Type set to Bug

comment:5 Changed 3 years ago by lukeplant

  • Severity set to Normal

Changed 3 years ago by ShawnMilo

Changes at Russell's suggestion.

comment:6 Changed 3 years ago by ShawnMilo

  • Easy pickings set
  • Has patch set

comment:7 follow-up: Changed 3 years ago by anonymous

Should emphasize that you get an empty test database for each test case.

comment:8 in reply to: ↑ 7 Changed 3 years ago by ShawnMilo

Replying to anonymous:

Should emphasize that you get an empty test database for each test case.

Do you mean that it should be made clear that the fixtures are refreshed for each test? If so, that's a good point, and non-obvious.

Shawn

comment:9 Changed 3 years ago by ShawnMilo

  • Owner changed from nobody to ShawnMilo

comment:10 Changed 3 years ago by d0ugal

  • Cc dougal85@… added

comment:11 Changed 3 years ago by SmileyChris

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

In [16214]:

Fixes #15595 -- emphasize the benefits of django.test.TestCase. Thanks for the patch Shawn Milochik

comment:12 Changed 3 years ago by SmileyChris

In [16215]:

[1.3.X] Fixes #15595 -- emphasize the benefits of django.test.TestCase. Thanks for the patch Shawn Milochik

Backport of r16214 from trunk.

comment:13 Changed 3 years ago by d0ugal

  • Cc dougal85@… removed

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.