New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor test_class to use unittest lib #44638
Comments
Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. |
Thanks for your effort! This generally looks good. A few minor things:
|
Hi collin,
Let me know if you have further suggestions. |
Note that you don't need the global statement for callLst as you aren't rebinding it in the function. |
Removed unnecessary global statement in trackCall. Anything else? :-) |
Mike, I've tweaked your refactoring some: strengthened the assertions in testMixIntsAndLongs and testDel; code cleanup in testBadTypeReturned; removed Jython-related code; reduced line lengths to < 80; changed a few print statements to self.fail() calls. Look over the version I've uploaded and tell me what you think. |
Hi Collin, Sorry for the delay. Your tweaks look very good. I don't see any problems. |
This patch looks good to me. |
There should be a test_main method otherwise this won't work when called from regrtest. Have you tried to run this with regrtest -R :: ? I think it will work, but just wanted to be sure. One thing that might be nice to add to this test is to verify the change in the length of the callLst since assertLastCallWas() was called. Typically there should be only one method call from what I saw in the test. However, if we screw something up and there are two method calls, this test could catch that. It would be an enhancement (ie new feature) over the existing test. |
Hi all, Good catch Neal, I needed a test_main method. I also finally got around to tightening up the tests so that at all times the entire call stack is tested. It's a bit messier than before and somewhat brittle, but it's thorough and checks every ugly implicit call to __coerce__ just like the old tests did. Only problem is that now the tests fail. The test of the statement "1 == testme" on line 419 generates a call stack that seems very strange and I can't figure out what it means. It might be a bug in the python interpreter... or a feature... or just a mistake in the test. At this point I can't figure it out but I'll post my patch so far. If anyone can figure out what's going on please let me know! |
I've figured out the problem with your call stack: the comparison of I've fixed this, but the new test still fails with regrtest -R:: -- will |
Argh, the test modified the state of one of its classes. Fixed that and committed now as rev. 57409. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: