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

[Kenneth Gonsalves]

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.

[MikeRamirez]

I've given this thought on this here: ​http://groups.google.com/group/django-users/msg/b8d978e840be3905

[Kenneth Gonsalves]

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.

[Russell Keith-Magee]

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.

[ShawnMilo]

Changes at Russell's suggestion.

[anonymous]

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

[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

[Chris Beaven]

In [16214]:

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

[Chris Beaven]

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.