[Python-Dev] no expected test output for test_sort? (original) (raw)
Walter D�rwald walter@livinglogic.de
Fri, 10 Jan 2003 14:16:16 +0100
- Previous message: [Python-Dev] no expected test output for test_sort?
- Next message: [Python-Dev] new features for 2.3?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Raymond Hettinger wrote:
[Walter]
So should I go on with this? Do we want to change all tests before 2.3 is finished, or start changing them after 2.3 is released (or something in between)? [GvR] I'd say something in between. It's probably good if someone (not me) reviews your patches. [Walter] Definitely. Any volunteers? I'll review a few of these but cannot sign-up for the whole ball game because of time constraints, inability to run certain modules, and trying to review only things I thoroughly understand.
And I won't change any tests that I don't understand, so we'll probably won't change the whole test suite.
My own hope for your project is that new tests are made, coverage increased, interfaces are checked to the document specification, and bugs are found. I'm much less enthusiastic about having existing tests converted to unittest format.
The old version of test_pow.py had the following code
print 'The number in both columns should match.'
print pow(3,3) % 8
, pow(3,3,8)
Something like this is nearly impossible to spot in the output of regrtest.py. Porting all tests to PyUnit makes the output more uniform and it's easier to spot problem.
Furthermore porting the old tests to PyUnit gives hints about what features are still missing from PyUnit: For example I've missed a method assertFuzzyEqual(), that does the equivalent of test.test_support.fcmp(), and an assertIs() would also be helpful.
Bye, Walter D�rwald
- Previous message: [Python-Dev] no expected test output for test_sort?
- Next message: [Python-Dev] new features for 2.3?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]