Opened 17 years ago
Closed 15 years ago
#6364 closed (fixed)
Allow test runner to execute individual doctests
Reported by: | David Larlet | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Keywords: | testing | |
Cc: | Russell Keith-Magee, Dan Fairs, Robin, David Larlet | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
For the moment, you can specify a test case or even a single test method in this test case but you can't use more than one doctest file easily and run tests file by file for instance.
The attached patch allow you to run doctests from your tests/ directory one by one:
python manage.py test app.doctest_filename_without_extension
Or all at once:
python manage.py test app
You just need doctests files with ".txt" extension. Comments are welcome.
Update: doctests can already be split across files using __tests__. However, the ability to execute tests on a fine grained level would be useful.
Attachments (1)
Change History (14)
by , 17 years ago
Attachment: | patch_django_6364.diff added |
---|
comment:1 by , 17 years ago
Owner: | changed from | to
---|
comment:2 by , 17 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Triage Stage: | Unreviewed → Ready for checkin |
comment:3 by , 17 years ago
Thanks Simon, I know there are a lot of improvements to do (better error handling, documentation, etc) but I'd like to know if core is interested in this approach before spending too much time on this.
comment:4 by , 17 years ago
Cc: | added |
---|---|
Triage Stage: | Ready for checkin → Design decision needed |
Let's not do this. It introduces "yet another way" to specify tests. Multiple doctests can already be specified via the __tests__
variable, so what we need is a way to identify them. Possibly <app_name>.<test_key>
where test_key
is the key name in the __tests__
dictionary might be most straightforward here.
Russell probably needs to have some input, too, since I have a recollection he's thought about this in the past.
[Triagers: please use "design decision needed" for these types of tickets, not "ready for checkin", which is for non-controversial, fully complete stuff.]
comment:5 by , 17 years ago
Description: | modified (diff) |
---|---|
Patch needs improvement: | set |
Summary: | Allow fine grained tests for doctests (allow splitting into many files) → Allow test runner to execute individual doctests |
Triage Stage: | Design decision needed → Accepted |
I'm all in favour of the idea of greater granularity for running doctests. However, as Malcolm rightly points out, doctests already provide a multi-file option through the __tests__ dictionary. The Django test runner should supplement, not replace this approach.
Invoking parts of a __tests__ dictionary would certainly be a valuable contribution, but it doesn't completely solve the problem. Doctests can be defined inline on a method or class (the classic sense of a doctest); it would be nice to be able to invoke these individual tests, too.
I'll mark this as accepted, but for the concept, not the provided implementation. I've updated the ticket to better reflect the accepted idea.
comment:6 by , 17 years ago
Ok, I'll try to do something with __tests__, thanks for your suggestions. Inline doctests looks a bit trickier at first sight.
comment:7 by , 16 years ago
Component: | Tools → Testing framework |
---|
comment:8 by , 16 years ago
Owner: | changed from | to
---|
Reverting to nobody since no progress has been made for a while.
comment:9 by , 15 years ago
Cc: | added |
---|
comment:10 by , 15 years ago
Cc: | added |
---|
comment:11 by , 15 years ago
Cc: | added |
---|
Since [12255], I think this issue should be fixed by a snippet and is not anymore required as a trunk addition. As I understand it, it's now as easy as overriding DjangoTestSuiteRunner.build_suite with a call to doctests or whatever.
comment:12 by , 15 years ago
@david - no this is still a trunk problem. The new class-based structure will make this easier to do as a snippet while you wait for a final patch to hit trunk, but that doesn't remove the need for a solution in trunk.
comment:13 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Sounds like a rather good idea. I'll move to RFC and see what core says