Title: Refactor test_class to use unittest lib
Type: Stage:
Components: Tests Versions: Python 2.6
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: collinwinter, georg.brandl, jerry.seutter, jyzude, nnorwitz
Priority: normal Keywords: patch

Created on 2007-02-28 22:38 by jyzude, last changed 2007-08-24 19:34 by georg.brandl. This issue is now closed.

File name Uploaded Description Edit
test_class.patch jyzude, 2007-02-28 22:38 Patch to convert to use unittest library
test_class.patch jyzude, 2007-03-06 06:38 Updated patch with modifications recommended by Collin Winter
test_class.patch jyzude, 2007-03-07 21:07 Removed unnecessary global statement collinwinter, 2007-03-11 17:42 Tweaks by Collin Winter
test_class.patch jyzude, 2007-04-24 05:57 Way more thorough replacement for
Messages (12)
msg52010 - (view) Author: Mike Verdone (jyzude) Date: 2007-02-28 22:38
Refactored Lib/test/ to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch.
msg52011 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2007-03-06 00:11
Thanks for your effort!

This generally looks good. A few minor things:

- testMixIntsAndLongs doesn't have any assertions in it.
- "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods.
- I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list.
msg52012 - (view) Author: Mike Verdone (jyzude) Date: 2007-03-06 06:38
Hi collin,

* I improved testMixIntsAndLongs. It now asserts things
* assert is banished, replaced by the correct calls
* the reason why callLst is global is because I have to track calls to __getitem__ in some cases. Because of this, if I put callLst on the object I end up with horrible recursive loops, or at the very least the last call on the stack will always be __getitem__ when I get the list to inspect.
* assertLastCall only checks the last thing on the list because generally the thing called before that is always __getitem__ or associated magic. I don't want my tests to be bound to the  internals of __getitem__. All I care about is that ultimately the right function was called. That said, I modified assertLastCallWas to erase the callLst to prevent any possible bleed-over from the previous test.

Let me know if you have further suggestions.
File Added: test_class.patch
msg52013 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-03-07 01:03
Note that you don't need the global statement for callLst as you aren't rebinding it in the function.
msg52014 - (view) Author: Mike Verdone (jyzude) Date: 2007-03-07 21:07
Removed unnecessary global statement in trackCall.

Anything else? :-)
File Added: test_class.patch
msg52015 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2007-03-11 17:42
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 calls. Look over the version I've uploaded and tell me what you think.
File Added:
msg52016 - (view) Author: Mike Verdone (jyzude) Date: 2007-03-19 22:23
Hi Collin,

Sorry for the delay. Your tweaks look very good. I don't see any problems.
msg52017 - (view) Author: Jerry Seutter (jerry.seutter) * (Python committer) Date: 2007-04-18 17:45
This patch looks good to me.
msg52018 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2007-04-19 06:17
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.
msg52019 - (view) Author: Mike Verdone (jyzude) Date: 2007-04-24 05:57
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!
File Added: test_class.patch
msg55270 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-08-24 19:19
I've figured out the problem with your call stack: the comparison of
callLst with the expected calls adds more calls to callLst, leading to a
failing comparison.

I've fixed this, but the new test still fails with regrtest -R:: -- will
msg55271 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-08-24 19:34
Argh, the test modified the state of one of its classes.

Fixed that and committed now as rev. 57409.
Date User Action Args
2007-08-24 19:34:25georg.brandlsetstatus: open -> closed
assignee: collinwinter -> georg.brandl
resolution: accepted
messages: + msg55271
2007-08-24 19:19:47georg.brandlsetmessages: + msg55270
2007-02-28 22:38:44jyzudecreate