Opened 14 years ago
Closed 12 years ago
#15919 closed Bug (worksforme)
Test failure on specific label
Reported by: | Berislav Lopac | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In Django 1.3, running a test or test case using a full label (e.g. manage.py test appname.TestCaseClass.test_name
as opposed to just manage.py test appname
) fails with the message: ValueError: Test label 'appname.TestCaseClass.test_name' does not refer to a test.
The exact same test code runs fine when run as part of a full suite ( manage.py text appname
), as well as on Django 1.2.
Change History (3)
comment:1 by , 14 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 12 years ago
Easy pickings: | set |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
UI/UX: | unset |
Version: | 1.3 → 1.4 |
This issue shows up if the tests are defined in the application using the suite(). The django.test.simple.build_suite() function has support for such arrangement (which is why testing the whole app works), but django.test.simple.build_test() does not which is why running a single test class or test case fails with the above error. The fix would be to call build_suite in build_test and then iterate over the TestSuite, just like it is done in the Doctest code in the same function.
comment:3 by , 12 years ago
Easy pickings: | unset |
---|---|
Resolution: | → worksforme |
Status: | reopened → closed |
Version: | 1.4 → 1.3 |
@aigarius, considering that build_test()
method did not change from Django 1.2 to 1.3 (or 1.4 even), the issue you are describing doesn't match description of this one. Please create a new issue describing your problem. Thanks.
I can't reproduce this - it works fine for me on Django 1.3 and trunk. You'll need to provide more information to show this is a bug in Django and not in your code. However, I think this may well be #15638 you are describing, which is fixed in trunk.