Chris Jerdonek added the comment:
> Personally I prefer to have the test case create the file(s) used in the test
> dynamically, writing them to the temporary working directory.
I prefer that too, but when I approached this issue, I found that test_doctest
doesn't use unittest. It uses only doctest tests to test itself, and it uses
checked-in files to test things like DocTestSuite and DocFileSuite. For
example, test_DocFileSuite has this:
>>> suite = doctest.DocFileSuite('test_doctest.txt',
... 'test_doctest2.txt',
... 'test_doctest4.txt')
(Hence the eight supporting files I mentioned in my previous comment, of which
these are three.)
Should I break the current way of doing things for this module and introduce
unittest and the first dynamically created files?
> We have in the past put notes in the doc that say "this may change in the
> future", though that is usually about desired enhancements.
That's interesting. It's like a "Will change in version ..." counterpart to
"Changed in version ...." Come to think of it, that could be a useful practice
in general because it would let people future-proof their code more easily and
give them incentives to upgrade.
To simplify things for the purposes of this issue, we can discuss adding such
wording to earlier versions only if and when we actually change the future
behavior. I can create a separate issue to discuss changing future behavior
once this issue is complete.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14649>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
