> Test_descrtut is driving me up the wall (or actually, the whole test
> suite is:-).
>
> If I run it from regrtest it fails with the completely useless message
> test_descrtut
> The actual stdout doesn't match the expected stdout.
> This much did match (between asterisk lines):
> **********************************************************************
> test_descrtut
> **********************************************************************
> Then ...
> We expected (repr): ''
> But instead we got:
> '*****************************************************************\n'
> test test_descrtut failed -- Writing:
> '*****************************************************************\n',
> expected: ''
>
> If I run it standalone it doesn't work because all the typenames are
> different. This is a general problem, I've seen the same on unix.
>
> In general, I find the new test framework not much of an
> improvement. Whereas with old tests you would get some indication as
> to what was failing, currently it is at best a not very helpful "We
> expected '' But in stead we got 'TestFailed'", and at worst something
> like the above.
The problem seems to be that both doctest (which is just *one* of the
new test frameworks -- the other one is unittest) and regrtest (the
regression test suite driver) are trying to be friendly when they
encounter a failed test. One of the tests fails, and doctest prints
its failure message, which looks something like this:
*****************************************************************
Failure in example: C().foo()
from line #23 of test_descrtut.__test__.tut8
Expected: zcalled A.foo()
Got: called A.foo()
*****************************************************************
1 items had failures:
1 of 6 in test_descrtut.__test__.tut8
***Test Failed*** 1 failures.
But regrtest, which is comparing the output to the contents of the
file Lib/test/output/test_descrtut, doesn't expect that kind of
output, so *it* attempts to print a report of a failure, which looks
something like this:
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
**********************************************************************
test_descrtut
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: 'Blargh'
test test_descrtut failed -- Writing: 'Blargh', expected: ''
Except that if a doctest test fails, the unexpected output is not
'Blargh' but a line of asterisks followed by a newline. The unexected
output is repeated twice in the regrtest output.
The trick to finding out what's wrong with the test is to run it as
follows:
./python Lib/test/regrtest.py -v test_descrtut
This runs the test in "verbose mode", and in that mode regrtest
doesn't do its output comparison trick -- it just shows you all the
test's output. Now, doctest also scans sys.argv for a -v (which I
think is wrong because it's not the main program, but that's how it
works), and this causes doctest to be much more verbose -- which may
or may not be helpful but shouldn't be a problem unless you are
without a scrollbar.
You said that when you run the test standalone the type names are
different. *How* do you run it standalone? If I run it like this:
./python Lib/test/test_descrtut.py
it works fine (and -v works here too). But if I run it like this:
./python
>>> import test.test_descrtut # this does not run the tests!
>>> test.test_descrtut.test_main() # this does!
then indeed doctset complains that instead of
<type 'test_descrtut.defaultdict'>
it saw
<type 'test.test_descrtut.defaultdict'>
(and other failures, all caused by the incorporation of the module
name (__name__) in type names when they are printed).
It is possible to rewrite the tests to avoid the dependency
on the module name: change all occurrences of test_descrtut to
test.test_descrtut, including the three places in the test_main()
function. But since it's not my test, I'll leave that to Tim.
(If you've been paying attention, you might have wondered why it
succeeded when run from the command line. Shouldn't the module name
be __main__ there? This is because of a trick employed by doctest: it
reimports the module!)
This still doesn't solve your real problem (that test_descrtut fails),
but the regrtest.py -v trick should make it possible for you to find
out painlessly. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4