[Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2)
SourceForge.net
noreply at sourceforge.net
Sat Dec 13 17:46:09 EST 2003
Patches item #736962, was opened at 2003-05-13 06:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470
Category: Tests
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Walter Dörwald (doerwalter)
Summary: Port tests to unittest (Part 2)
Initial Comment:
Here are the next test scripts ported to PyUnit:
test_winsound and test_array. For test_array many
additional tests have been added (code coverage is at 91%)
----------------------------------------------------------------------
>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 17:46
Message:
Logged In: YES
user_id=33168
Looked good to me, test_future_pyunit.diff checked in as:
* Lib/test/badsyntax_future3.py 1.2
* Lib/test/badsyntax_future4.py 1.2
* Lib/test/badsyntax_future5.py 1.2
* Lib/test/badsyntax_future6.py 1.2
* Lib/test/badsyntax_future7.py 1.2
* Lib/test/badsyntax_future8.py 1.1
* Lib/test/badsyntax_future9.py 1.1
* Lib/test/test_future.py 1.7
* Lib/test/test_future1.py 1.3
* Lib/test/test_future2.py 1.2
* Lib/test/output/test_future 1.4
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-13 16:47
Message:
Logged In: YES
user_id=33168
Walter, I didn't get a mail from SF either. After you do a
cvs add, you need to use -N to cvs diff. For example, cvs
diff -N new_file_added_to_cvs_but_not_committed. If you
look carefully, you can see this in the patch on the diff
line for each file. I'll take a look at the patch.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-12-13 15:18
Message:
Logged In: YES
user_id=89016
Here is a version of test_future ported to PyUnit
(test_future_pyunit.diff). If this makes sense to you Neal,
please check it in.
(BTW, how did you convince CVS to include
badsyntax_future8.py and badsyntax_future9.py in the diff?
Doing a "cvs add" only results in "
Lib/test/badsyntax_future8.py is a new entry, no comparison
available")
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-12-11 07:36
Message:
Logged In: YES
user_id=89016
md5/weakref patch checked in as:
Lib/test/test_weakref.py 1.33
Lib/test/test_md5.py 1.5
Lib/test/output/test_md5 remove
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 01:05
Message:
Logged In: YES
user_id=33168
Improve coverage for test_future too. I'm not sure if test
future can be ported to PyUnit.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-11 00:52
Message:
Logged In: YES
user_id=33168
Attached are two tests (in one file, I'm being lazy, sorry)
to improve test coverage for md5c.c and _weakref.c.
test_md5 was ported to unittest, weakref, just adds two
little tests to get coverage up to 100%. If you like, just
go ahead and check in. You will need to remove
Lib/test/output/test_md5
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-12-08 06:42
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/list_tests.py 1.1
Lib/test/seq_tests.py 1.1
Lib/test/test_list.py 1.1
Lib/test/test_tuple.py 1.1
Lib/test/test_types.py 1.56
Lib/test/test_userlist.py 1.11
Lib/test/output/test_types 1.3
Next will be test_binascii.py before I continue with
test_types.py.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-07 18:49
Message:
Logged In: YES
user_id=80475
Looks good.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-11-27 14:48
Message:
Logged In: YES
user_id=89016
Here the first part of the test_types port: list and tuple
tests have been moved to their own scripts: test_tuple.py
and test_list.py. Common tests for tuple, list and UserList
are shared (in seq_test.py and list_test.py)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 21:53
Message:
Logged In: YES
user_id=80475
Applied as:
Lib/test/test_slice.py 1.5.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-31 19:52
Message:
Logged In: YES
user_id=80475
Looks good.
I added a couple of minor tests.
Revised patch attached.
Okay to apply.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-08-31 15:49
Message:
Logged In: YES
user_id=89016
Thanks! Here's another one: test_slice.py
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-30 19:04
Message:
Logged In: YES
user_id=80475
Done.
See:
Lib/test/test_longexp.py 1.9; previous revision: 1.8
Lib/test/test_pep263.py 1.3; previous revision: 1.2
Lib/test/test_sets.py 1.27; previous revision: 1.26
Lib/test/test_structseq.py 1.5; previous revision: 1.4
Lib/test/output/test_longexp delete; previous revision: 1.3
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-30 13:10
Message:
Logged In: YES
user_id=80475
Will do!
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-08-30 13:06
Message:
Logged In: YES
user_id=89016
Here's test_structse.py converted with a few additional
tests. If all three scripts are OK, could you check them in
Raymond, as I'll be on vacation for three weeks?
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-08-09 11:47
Message:
Logged In: YES
user_id=89016
Here are two simple ones: test_pep263 and test_longexp. I
can't think of any additional tests to add.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-23 09:38
Message:
Logged In: YES
user_id=80475
Fixed Walter's review comments and
committed as Lib/test/test_compile.py 1.19
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-23 07:49
Message:
Logged In: YES
user_id=89016
Are you sure, that the code path is the same in the new
test_argument_handling() as in the old test? I.e. is
"eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"?
The print statement in test_float_literals should be changed
to a comment.
Should the imports in test_unary_minus() be moved to the
start of the script?
Otherwise the test looks (and runs) OK.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-20 15:26
Message:
Logged In: YES
user_id=80475
Here's one for you:
test_compile.py is ready.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-19 05:46
Message:
Logged In: YES
user_id=89016
Maybe test_types.py should be split into several scripts:
test_dict, test_tuple, test_list, test_int, test_long etc.
Some of them already exist (like test_long), some don't. The
constructor tests from test_builtin should probably be moved
to the new test scripts as well. Furthermore we should try
to share as much testing functionality as possible (e.g.
between test_int and test_long, or between test_list and
test_userlist)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-18 15:48
Message:
Logged In: YES
user_id=80475
Great!
Can I suggest that test_types.py be next.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-18 10:27
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/test_builtin.py 1.21
Lib/test/test_complex.py 1.10
(I've moved the constructor tests from test_builtin to
test_complex)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-17 19:49
Message:
Logged In: YES
user_id=80475
I added a few tests. If they are fine with you, go ahead and
commit.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-17 17:36
Message:
Logged In: YES
user_id=89016
Here's the next one: text_complex.py.
There one test that's currently commented out, because it
crashes Python on Alpha (see http://www.python.org/sf/756093.
The old test scripts states that tests for the constructor
are in test_builtin, but I've added many tests to this
script, so this is no longer true. We could move the tests
to test_builtin, but IMHO that doesn't make sense, we'd
better move the rest of the constructor tests from
test_builtin to test_complex.
I'd like to have a version of assertAlmostEqual() in
unittest.py that can cope with complex numbers, but this
would have to be coordinated with the standalone version of
PyUnit (and it would probably have to wait until the 2.4
cycle starts) (I noticed that there is no assertAlmostEqual
in the code on pyunit.sf.net anyway.)
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-17 08:06
Message:
Logged In: YES
user_id=89016
I'd like to keep this patch open, as it is an ongoing task
(the next test scripts to be converted will be test_complex
and then maybe test_marshal)
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 17:55
Message:
Logged In: YES
user_id=357491
OK, all tests pass cleanly. Applied as revision 1.6.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-16 15:51
Message:
Logged In: YES
user_id=89016
The joys of unittesting: Breaking code to make it better! ;)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 15:41
Message:
Logged In: YES
user_id=80475
Okay, it runs fine here. Once Brett confirms that it runs on
the Mac, go ahead and load it.
P.S. Your improved test_mimetools.py helped detect a latent
error in mimetools.py when it was run under Windows. Tim
made the fix this weekend.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-16 15:33
Message:
Logged In: YES
user_id=89016
Strange, I didn't get this failure here, but I got it on my
laptop at home. I've removed the comparison with the
getatime() value from test_time(). I hope this fixes it.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 15:09
Message:
Logged In: YES
user_id=80475
Walter, there is one failure left:
======================================
================================
FAIL: test_time (__main__.PosixPathTest)
-------------------------------------------------------------------
---
Traceback (most recent call last):
File "test_posixpath.py", line 125, in test_time
self.assert_(
File "C:\PY23\lib\unittest.py", line 268, in failUnless
if not expr: raise self.failureException, msg
AssertionError
Brett, after Walter revises the patch, just load the patch and
make sure the test runs on the Mac. Between the three of
us, we can validate the suite on three different platforms.
Cheers.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-06-16 14:20
Message:
Logged In: YES
user_id=357491
Just wanting to work me like a dog, huh, Raymond? =)
And to clarify for my and Walter's benefit, when you say guards,
you mean that the tests don't crap out and say they failed on
Windows, right? I thought posixpath was not meant to work
under Windows.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-16 14:09
Message:
Logged In: YES
user_id=89016
I didn't realize that test_posixpath must work on Windows
too. Here's a new version.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 12:04
Message:
Logged In: YES
user_id=80475
The previous comment applied to another patch.
It should have said:
Assigning to Brett to make sure the patch runs on the Mac.
Don't accept this one until it has guards that allow the tests
to run on Windows.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 11:59
Message:
Logged In: YES
user_id=80475
Assigning to Brett to give experience doing a detail review on
this type of change.
* examine every line of the diff and consider whether there is
any semantic change (exceptions raised, etc).
* apply the diff and run the test suite
* in the interactive mode, call-up each function and make
sure it behaves as expected (this is necessary because the
test coverage is very low).
* verify that the whitespace has been cleaned up.
* look for missing changes (such as use of +=)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-16 11:44
Message:
Logged In: YES
user_id=80475
The test file now has dependencies that do not apply to
windows. The failure messages are attached.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-06-16 08:48
Message:
Logged In: YES
user_id=89016
Here's the next one: test_posixpath.py with many additional
tests.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-05-22 13:33
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/output/test_mimetools delete
Lib/test/test_mimetools.py 1.4
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 12:18
Message:
Logged In: YES
user_id=80475
test_mimetools.py is ready.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-05-22 11:05
Message:
Logged In: YES
user_id=89016
I've attached a third version of test_mimetools.py that does
some checks for the mimetools.Message class.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-21 09:04
Message:
Logged In: YES
user_id=80475
Attaching a slightly modified test_mimetools which covers
more encodings and has a stronger set test.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-05-18 19:46
Message:
Logged In: YES
user_id=89016
Agreed, this is too much magic for too little gain.
Back to business: Here is test_mimetools ported to PyUnit.
Tests for mimetools.Message are still missing. If you can
think of any tests please add them.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-17 23:18
Message:
Logged In: YES
user_id=80475
Get the module with sys.modules:
tests = test_support.findtestclasses(sys.modules
[__name__])
test_support.unittest(*tests)
Yeah, the inheritance thing is a problem. I was trying to
avoid having to modify unittest.TestCase to have a
metaclass. The control of the module is kept in a
separate SF project and one of its goals is to be backward
compatible through 1.5.2 (meaning no metaclasses).
A possible workaround is to define a modified testcase in
test_support so that people don't import unittest directly
anymore:
test_support.py
-------------------------
import unittest
class SmartTestCase(unittest.TestCase):
__metaclass__ = autotracktests
pass
test_sets.py
------------------
class TestBasicOps(test_support.SmartTestCase):
run = False
. . .
class TestBasicOpsEmpty(TestBasicOps):
def setUp(self):
. . .
Still, this is starting to seem a bit magical and tricky.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-05-17 22:52
Message:
Logged In: YES
user_id=89016
But how do I pass the module object from inside the module?
And skipping abstract classes seems to be more work in this
version: If skipping is done via a class attribute, derived
classes have to explicitely reset this flag because of
interitance.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-17 21:59
Message:
Logged In: YES
user_id=80475
Good call.
Instead of using metaclasses, perhaps add a module
introspector function to test_support:
def findtestclasses(mod):
tests = []
for elem in dir(mod):
member = getattr(mod, elem)
if type(member) != type: continue
if issubclass(member, unittest.TestCase):
tests.append(member)
return tests
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-05-17 21:45
Message:
Logged In: YES
user_id=89016
But this can be solved with a special non-inheritable class
attribute:
class BaseTest(unittest.TestCase):
run = False
Then the metaclass can do the following:
def __new__(cls, name, bases, dict):
if "run" not in dict:
dict["run"] = True
cls = type.__new__(cls, name, bases, dict)
if cls.run:
tests.append(cls)
return cls
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-17 21:04
Message:
Logged In: YES
user_id=80475
I don't think metaclasses or module introspection would
help whenever there are classes that derive from TestCase
but are not meant to be run directly (their subclasses have
the setup/teardown/or class data). test_sets.py has
examples of that kind of thing.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-05-17 20:50
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/test_array.py 1.20
Lib/test/test_winsound.py 1.5
Lib/test/output/test_winsound delete
> The approach of using tests.append() is elegant and
> makes it easier to verify that no tests are being omitted.
The most elegant approach would probably be a metaclass that
collects all TestCase subclasses that get defined. Classes
that only serve as a base class could be skipped by
specifying a certain class attribute.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-17 19:35
Message:
Logged In: YES
user_id=80475
The approach of using tests.append() is elegant and
makes it easier to verify that no tests are being omitted.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470
More information about the Patches
mailing list