Opened 15 years ago
Closed 13 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 , 15 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
comment:2 by , 13 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 , 13 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.