>>>>> "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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4