[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_userstring,1.1,1.2

[Jeremy Hylton]

>>>>> "PF" == Peter Funk <pf@artcom-gmbh.de> writes:

  PF> Hmmmm..... Wouldn't it be better to actually write some simple
  PF> test cases for these methods and add them to
  PF> 'Lib/test/test_string.py' (if not already done)?

  PF> My initial idea to put this check into 'test_userstring.py' was
  PF> to discover missing test cases for new methods that should be
  PF> copied from test_string.py in order to keep UserString in sync
  PF> with new functionality added to the builtin string types.

That sounds like a good testing strategy, but I'm not sure I agree
with a test that fails because it has failed to track a new feature.
The current test suite does a mediocre job of testing all features or
achieving code coverage.  It's annoying that this test is reported as
a failure when the module is, in fact, working properly.

In the long term, a revision of the testing setup so that different
classes of errors can be reported might be useful.  The failure to
test an encode method could be reported as a warning (non-fatal)
instead of an error (fatal).

I also don't like the implementation strategy, which causes code to be
duplicated in test_string.py and test_userstring.py.  I'll add a third
module that can be loaded by either test module to perform the
specific tests.

Finally, test_string doesn't test encode either.  Someone want to add
a test for that?

Jeremy