[Patches] [ python-Patches-662807 ] Port tests to unittest
SourceForge.net
noreply@sourceforge.net
Mon, 28 Apr 2003 11:42:16 -0700
Patches item #662807, was opened at 2003-01-05 21:50
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470
Category: Tests
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Port tests to unittest
Initial Comment:
This patch ports the three tests test_pow.py,
test_charmapcodec.py and test_userdict.py to unittest.
----------------------------------------------------------------------
>Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-28 20:42
Message:
Logged In: YES
user_id=89016
Here's the next one: test_richcmp.py with a few additional
tests to increase code coverage in object.c and listobject.c.
BTW, should we change all tests to use the new
test_support.run_classtests()?
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-25 13:40
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/test_bool.py 1.9
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 23:00
Message:
Logged In: YES
user_id=6380
I suggest not to mess with unittest.py; it is still
externally maintained as PyUnit. Maybe ask the PyUnit developer.
No time to review the test, sorry; if it works, I suggest to
just check it in. ;-)
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-23 22:33
Message:
Logged In: YES
user_id=89016
Here's the next one: test_bool.py ported to PyUnit with a
few additional tests. Code coverage for boolobject.c is at 100%.
Would it make sense to move assertIs() and assertIsNot() to
unittest.py?
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-15 13:30
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/output/test_pwd delete
Lib/test/test_pwd.py 1.13
Lib/test/test_grp.py 1.11
Lib/test/test___all__.py 1.29
(with
if __name == '__main__':
test_main()
added to test_pwd)
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-15 01:09
Message:
Logged In: YES
user_id=33168
Sorry, you are correct. I removed the output/test_pwd and
the test passes. This is on redhat 9 now.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-14 14:31
Message:
Logged In: YES
user_id=89016
Neal, are you sure the error you get isn't just from the
output comparison? Can you post a traceback? test_pwd works
for me with Redhat 7.3.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-13 11:07
Message:
Logged In: YES
user_id=89016
> question why do you use 3 lines in test_main,
> rather than the old way? --
> test_support.run_unittest(Test)
The example in Lib/test/README seems to suggest that it
should be done this way.
I'll look into the test_pwd problem tomorrow.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-12 03:54
Message:
Logged In: YES
user_id=33168
question why do you use 3 lines in test_main, rather than
the old way? -- test_support.run_unittest(Test)
test___all__ is fine
test_grp is fine
test_pwd fails for me on Redhat 7.2. It also needs an
if __name == '__main__':
test_main()
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-10 11:10
Message:
Logged In: YES
user_id=89016
Here's an updated test_grp that executes tests equivalent to
those in test_pwd
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-04-10 10:46
Message:
Logged In: YES
user_id=89016
Here's the next one: test_pwd
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-03-11 20:15
Message:
Logged In: YES
user_id=89016
Here's the next one: test___all__.py ported to PyUnit and
updated.
A better solution might be to replace __builtin__.__import__
in regrtest.py and test for the __all__ attribute there.
Additionally this might allow us to check which modules are
imported by regrtest.py and which are not and require
additional tests.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-26 16:08
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/test_ucn.py 1.12
Lib/test/test_unicodedata.py 1.7
Lib/test/output/test_ucn delete
Lib/test/output/test_unicodedata delete
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-02-26 14:42
Message:
Logged In: YES
user_id=38388
test_ucn and test_unicodedata look OK.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-25 18:53
Message:
Logged In: YES
user_id=89016
OK, here are the next few ports: test_ucn and
test_unicodedata. I'm not actually sure, whether changing
test_unicodedata (which uses the comparison of generated
output with expected output) is a good thing, as now updates
to the database require manual changes. I've added a few
error checks which increase coverage in unicodedata.c from
87% to 95%.
Marc-André can you check if this is OK?
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-21 14:05
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/string_tests.py 1.27
Lib/test/test_str.py 1.1
Lib/test/test_string.py 1.24
Lib/test/test_unicode.py 1.79
Lib/test/test_userstring.py 1.10
Lib/test/output/test_string delete
I've removed the sets import and renamed the mixin tests to
contain the relevant class/module names (e.g.
MixinStrStringUserStringTest)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-21 04:39
Message:
Logged In: YES
user_id=80475
* test_string.py imports sets but does not use it.
* the names of the mixin classes could possibly
be made clearer so I won't have to search into
the comments to find-out which mixins are
appropriate for each class.
Overall, it looks like a nice factoring job and ought
to go a long ways toward keeping these guys
in sync in the future.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-17 19:29
Message:
Logged In: YES
user_id=89016
Here is the next bunch of ports: the string tests have been
ported to PyUnit and made as reusable as possible. Tests are
now shared between str, unicode, UserString and the string
module. As a result of reusing a part of the unicode tests
for str, the coverage in stringobject.c goes from 83% to
86%. Furthermore it should help keep the API consistent
between str and unicode (Example: "%c" % 0xffffffff raises
OverflowError, u"%c" % 0xffffffff raises ValueError)
Raymond can look look through the scripts and check that
everything is OK?
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-16 10:33
Message:
Logged In: YES
user_id=89016
I'm currently working on a PyUnit port of the string tests (i.e.
str, unicode, UserString and the string module). Uploading
the result to this patch would be easier, as it already has a
establsihed audience: But I can open a new patch for that if
you want.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-14 21:11
Message:
Logged In: YES
user_id=33168
Walter, can this patch be closed now?
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-14 12:30
Message:
Logged In: YES
user_id=89016
Checked in as:
Lib/test/output/test_charmapcodec delete
Lib/test/test_charmapcodec.py 1.6
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-02-14 09:52
Message:
Logged In: YES
user_id=38388
test_charmapcodec looks OK. Just remove
the DOS-lineends before checking it in.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-13 19:16
Message:
Logged In: YES
user_id=89016
OK, checked in as test_userlist.py 1.7.
Assigned back to MAL for the review of test_charmapcodec.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-13 19:08
Message:
Logged In: YES
user_id=6380
Walter, feel free to check in test_userlist.py!
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-13 19:02
Message:
Logged In: YES
user_id=89016
Here's another one: test_userlist has been ported to PyUnit
and a few tests have been added to increase coverage.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-13 04:12
Message:
Logged In: YES
user_id=33168
MAL, could you look at the test_charmapcodec.py? I think
that's the only file outstanding from this patch. It's a
pretty straightforward test.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-04 00:13
Message:
Logged In: YES
user_id=89016
OK, test_sys.py is checked in.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-03 23:56
Message:
Logged In: YES
user_id=6380
I think you can check this in -- if it fails with Jython,
Finn or Samuele will quickly patch it. :-)
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-03 23:44
Message:
Logged In: YES
user_id=89016
OK, here's a new test_sys.py
> test_sys.py:
>
> - I agree that it's not worth testing the code
> paths that will invoke a custom __displayhook__ or
> __excepthook__, but I regret it nevertheless. :-)
> maybe this deserves a comment?
Testing a custom displayhook is now done (via compile(...,
"single")/exec). Testing a custom excepthook seems to be
trickier. This could probably be done by calling the
interpreter recursively via os.system() or os.popen(). I've
added a comment for now that this isn't tested.
Unfortunately this leaves a large block in
Python/pythonrun.c uncovered.
> - sys.exit() should also be callable with a string
OK, done.
> - you could check that the value of the SystemExit exception
> has the right exit code
Done.
- Have you checked this with Jython? I don't know if it
implements all
of these; in particular I doubt it has getrefcount().
I haven't tested Jython yet, but I guess test_sys.py will
have to many many exceptions for Jython. I'll try this tomorrow.
- I presume you've tested this on Windows?
Linux & Windows
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-03 22:10
Message:
Logged In: YES
user_id=6380
test_sys.py:
- I agree that it's not worth testing the code paths that
will invoke a custom
__displayhook__ or __excepthook__, but I regret it
nevertheless. :-)
maybe this deserves a comment?
- sys.exit() should also be callable with a string
- you could check that the value of the SystemExit exception
has the right
exit code
- Have you checked this with Jython? I don't know if it
implements all
of these; in particular I doubt it has getrefcount().
- I presume you've tested this on Windows?
Sorry, I can't help you with charmapcodec
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-02-03 21:36
Message:
Logged In: YES
user_id=89016
Here's a new one: test_sys.py tests Python/sysmodule.c.
Coverage goes from 68% to 77%.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 15:46
Message:
Logged In: YES
user_id=80475
All are approved except test_charmapcodec.py --
someone else should look at that one.
Be sure to follow GvR's advice and replace assertEquals
with assertEqual.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-16 21:47
Message:
Logged In: YES
user_id=89016
test_unicode is ported and enhanced (coverage goes from
80.81% to 85.05%)
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 18:17
Message:
Logged In: YES
user_id=89016
> In general, don't do tests that hardwire implementation
details
So should we remove
self.assertEquals(reduce(42, "1"), "1")
self.assertEquals(reduce(42, "", "1"), "1")
from test_filter?
BTW, you should look at test_builtin first, as the others
are still simply ports to PyUnit.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 18:03
Message:
Logged In: YES
user_id=80475
Good to hear the news on increasing the coverage.
In general, don't do tests that hardwire implementation
details. Test it if it is a documented variable, exposed
through __all__, is a key constact (like the magic numbers
in random.py), or a variable that a module user is likely to
be relying upon. Otherwise, no -- it should be possible to
improve an implementation without crashing the suite.
I'll try to review a few of these over the next few days.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 17:53
Message:
Logged In: YES
user_id=89016
test_builtin.py is now updated to test more error
situations. This increases the coverage of bltinmodule.c
from 75.13% to 92.20%, and it actually revealed one or two
potential bugs:
http://www.python.org/sf/665761 and
http://www.python.org/sf/665835
I'm not 100% sure that test_intern() and test_execfile() do
the right thing.
I'm not sure, whether the test script should check for
undocumented implementation artefacts, like:
a = 1
self.assert_(min(a, 1L) is a)
but in this way at least we get notified if something is
changed unintentionally.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 20:05
Message:
Logged In: YES
user_id=89016
test_b1 and test_b2 are combined into test_builtin now
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 15:03
Message:
Logged In: YES
user_id=6380
Two random suggestions:
- a blank line before each method, even trivial ones, even
the first one
- use assertEqual, not assertEquals
BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 17:37
Message:
Logged In: YES
user_id=89016
test_b1.py has been ported too.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 21:56
Message:
Logged In: YES
user_id=89016
The patch is hard to read, so I'll upload all three test scripts.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470