Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Wed, Mar 9, 2011 at 2:32 AM, Scott Dial <rep...@bugs.python.org> wrote: .. > By rejecting unittests on the merits of its coding style, you are creating a > double-standard for people like > me (outside of the core committers), which eventually wears out my interest > in helping you get this > improvement into your project. I don't think there is a double-standard. What you see is more of an evolving standard in which we seek higher quality for the new code than that of the code already in. The readability of the test code is as important if not more important than the readability of the main code. It may be more important because in some cases you can trust obscure code if it is clear that tests cover all corner cases and are easy to understand. I don't think there are overly strict standards for how unit tests should be written, but when they are written in a style that is unfamiliar to the reviewer, it makes it harder to review. Note that a reviewer needs to worry about tests passing on multiple platforms, their behavior in failure scenarios, as well as other issues that contributors typically overlook. Stylistic issues often point out to real problems, but are easier to spot. For example, try/finally is more error prone than with statement. In fact, in your test "append" stream will not get closed if writing fails. You may think the resource leak on failure is not a big deal, but for some runners that execute tests repeatedly this may lead to spurious failures. The acceptance rate for a patch is proportional to the severity of an issue that it fixes and obviousness of the fix (including tests.) This patch fails on both counts. Looking at the history of the issue, I see that the patch was applied once but reverted because it caused a crash. See msg78161. This shows that the tests were not sufficiently thorough. Next, a patch was suggested with tests that did not fail without a patch. See msg111516. This probably shows that additional tests are needed for 3.2. These are the reasons I unassigned this issue. In my opinion it would take a committer too much effort to bring the patch to commit ready shape for the marginal benefit of fixing a platform dependent corner case. If the tests were better written so that it would be more obvious what is fixed and that nothing gets broken, my calculation would probably be different. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1706039> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com