Clean up/refactor/make discoverable test_decimal #64207
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = None closed_at = None created_at = <Date 2013-12-17.21:24:31.840> labels = ['type-feature', 'tests'] title = 'Clean up/refactor/make discoverable test_decimal' updated_at = <Date 2016-01-02.14:08:02.924> user = 'https://github.com/zware'
activity = <Date 2016-01-02.14:08:02.924> actor = 'serhiy.storchaka' assignee = 'none' closed = False closed_date = None closer = None components = ['Tests'] creation = <Date 2013-12-17.21:24:31.840> creator = 'zach.ware' dependencies =  files = ['33182'] hgrepos =  issue_num = 20008 keywords = ['patch', 'needs review'] message_count = 6.0 messages = ['206482', '206507', '206546', '247469', '257328', '257346'] nosy_count = 7.0 nosy_names = ['rhettinger', 'facundobatista', 'mark.dickinson', 'ezio.melotti', 'skrah', 'zach.ware', 'serhiy.storchaka'] pr_nums =  priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue20008' versions = ['Python 3.3', 'Python 3.4']
The text was updated successfully, but these errors were encountered:
This patch makes extensive changes to test_decimal, with the ultimate goal of making
Here's a (non-exhaustive) list of what the patch will do:
With the patch test_decimal can be run successfully: directly, by regrtest, or by unittest discovery in Lib/test/; with any acceptable combination of arguments when run directly; with or without _decimal; with or without -OO. I have not yet been able to test -DEXTRA_FUNCTIONALITY, --without-docstrings, or on any platform but Windows, but I don't expect any issues (of course :).
The patch is against default; 3.3 requires the removal of a usage of subTest and a tweaking of the Doctest expected results.
Any review will be very much appreciated!
Assigning to myself, since my private 100% coverage test suite
I have just glanced at the patch and only have some superficial
In any case, I would prefer a patch without stylistic changes. Elimination of "return" is a personal preference, so are the
Listing the tests explicitly is sometimes helpful, e.g. one can
Curiously enough, testing with a "polluted" context is also useful,
Finally, I *suspect* no one is using the command line arguments any
Stefan Krah wrote:
The returns were removed in bpo-19572, to reduce false positives in searching for silently skipped tests. I have no strong opinion on them beyond that; if you want them back I can put them back :)
The whitespace removals are just to make the test module consistent with itself, and I personally think it looks better with the removals. I can put the blank lines back too if need be. I don't think there are any stylistic changes that aren't also code changes beyond the blank lines removed.
The same can be accomplished by either deleting the test case after it is created (which wouldn't take much more editing of the file than commenting it out), or by using e.g.
True, but the real problem I ran into was tests changing the precision of the context, not changing it back, and the next test expecting the original precision (or a test expects a changed precision but gets the original). I'm fine with losing all of the new 'assertAndClearFlags' calls and the checking of flags (and even traps) in tearDown, but the precision changes cause headaches dependent upon test execution order. In fact, the only reason the tests pass right now is because of their ordering; if you random.shuffle(test_classes) before run_unittest(*test_classes), a few different failures pop up.
Another option would be to add another command line option to set random flags before each test.
(Note that I'm not terribly attached to either of the new command line options I've suggested in this message. They're just ideas I've had while thinking about your message, and have an idea how either could be implemented pretty easily if anyone else thought it was worthwhile since the command line parsing structure is already there. I don't plan to do anything with them without agreement from others.)
That may well be. It doesn't hurt anything to keep them, but it would make the patch quite a bit simpler to remove them. It might be useful in future though, and doesn't add that much more complexity to the module.