On 7/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 7/16/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On 7/16/07, guido.van.rossum <[email protected]> wrote: > > > Author: guido.van.rossum > > > Date: Tue Jul 17 02:34:25 2007 > > > New Revision: 56409 > > > > > > Modified: > > > python/branches/py3k-struni/Lib/test/test_exceptions.py > > > Log: > > > Make the test of chr() overflow pass. > > > (Sigh. There are so many redundant tests.) > > > > > > > Yep. But is there any good way of dealing with the issue? Beyond > > enforcing a more strict testing policy in terms of where certain tests > > go to make sure redundancy is minimized, I can't think of any good > > solution. > > Perhaps we should first set a policy, and then move/remove tests that > don't follow it. A strawman for a policy is that all behavior of a > particular class or function should be tested in the test suite for > that class / function. That would mean that if chr() is to raise a > specific exception, it should be tested with the other tests for > chr(), not with that exception.
Makes sense to me. How about having individual test files for the various built-ins? As of right now we have test_builtin, but also things like test_tuple and test_file without a test_chr. And then semantic stuff is all over (e.g., test_class, test_descr, test_binop, etc.). I would never expect a newbie to come along and know where to look for a semantic test. Should we make Lib/test less shallow and have like a builtins, language, stdlib, and capi subpackages to help organize this stuff and make the location of tests more obvious? That might help make it clearer where one should look and thus if a test for something is not found there it probably doesn't exist. -Brett _______________________________________________ Python-3000-checkins mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000-checkins
