Brian Zimmer wrote:
> As we're moving closer to an alpha we've been trying to get a handle
> on what tests should and should not be passing (because of CPython
> differences primarily or now unsupported features such as subclassing
> a Java class and a new-style Jython class).
> Part of the difficulty has been up until now the build did not copy
> all the necessary files from Lib/test into the dist/Lib/test directory
> so depending on which directory from which you ran regrtest you would
> get different results. This has caused some confusion.
well, one thing is that some tests in jython/Lib/test are obsolete, they
are just a older version of a corresponding CPython test and should be
removed, at one point
I started doing that but did not finish. This is related to the fact
that because in the deployment setup test are going to be mixed no tests
in jython/Lib/test should have the
same name of a CPython test unless it is meant to completely override
it. Right now regrtests with --broad option execute both tests sharing a
name in jython/Lib/test
and a subsquent Lib/test dir on sys.path (typically the CPython one),
but ideally in the absence of spurious clashes it should need to execute
only the first test encountered
along sys.path with a given name.
> I for one can't seem to figure out how to add a new test to the
> regrtest framework that prints to stdout such as test_sets which I
> copied from the Python 2.3 test set. I had to explictly set the
> test_support.verbose attribute to False otherwise the variances in the
> time taken to run the test caused the output to always diff.
> Another area is the bugtests respository which as far as I can tell is
> the only real source of jythonc tests. This has yet another test
> Also, testing the code from Java (not through jython) is rather
> cumbersome but Clark Updike did just add some tests for such work.
> Does anyone have a full handle on this stuff? Anyone want to help
> consolidate the testing frameworks?