Showing content from http://mail.python.org/pipermail/python-dev/attachments/20060604/f65fe514/attachment.htm below:
<br><div><span class="gmail_quote">On 6/4/06, <b class="gmail_sendername">Michael Hudson</b> <<a href="mailto:mwh@python.net">mwh@python.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
"Thomas Wouters" <<a href="mailto:thomas@python.org">thomas@python.org</a>> writes:<br><br>> On 6/4/06, Michael Hudson <<a href="mailto:mwh@python.net">mwh@python.net</a>> wrote:<br>> [ For non-checkins readers: Martin Blais checked in un-unittestification
<br>> of test_struct, which spawned questions form Neal and me about whether<br>> that's really the right thing to do. I also foolishly< 0.5 wink> siggested<br>> that, if we switch away from unittest, we switch to
py.test instead of the<br>> old unstructured tests ]<br>><br>> "Tim Peters" <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> writes:<br>> > unittest, and especially doctest, encourage breaking tests into small
<br>> > units. An example of neither is test_descr.py, which can be a real<br>> > bitch to untangle when it fails.<br>><br>> Also, there is an advantage to have more structure to the tests; if<br>
> all of python's tests used unittest, my regrtest -R gimmickery would<br>> be able to identify tests, rather than test files, that leaked and I'm<br>> pretty sure that this would have saved me a few hours in the last
<br>> couple of years. Also, you can more easily identify particular tests<br>> that fail intermittently. Etc.<br>><br>> I'm not arguing against structure, just against all the unittest cumber.<br>> For example,
py.test doesn't do the output-comparing, and it does require<br>> you to put tests in separate functions. However, it doesn't require (but<br>> does allow) test classes. Test-generators are generators that *return*<br>
> tests, which are then run, so that you can have separate tests for<br>> runtime-calculated tasks, and yet still have them be separate tests for<br>> error reporting and such. py.test also allows tests to print during
<br>> execution, and that output is kept around as debug output: it's only shown<br>> when the test fails. It also comes with a convenient command-line tool<br>> that can run directories, modules, individual tests, etc -- which, for
<br>> unittest, I *always* have to copy-paste select bits out of regrtest and<br>> test_support for. My own project testing has gotten much more exhaustive<br>> since I started using py.test, it's just much, much more convenient.
<br><br>I don't want to pull the 'do you know who I am?' routine, and I know<br>you're addressing python-dev rather than just me, but I'm currently<br>sitting in the same room as the guy who wrote py.test :-)<br><br>I'm also not sure what point you're trying to make: I *know*
py.test<br>is better than unittest, that's not what I was saying. But unittest<br>is better than old-skool output comparison tests.<br><br>I guess you're not really replying to my mail, in fact... :)</blockquote><div><br>
I'm sorry, I guess I was misunderstanding your mail. I thought Tim's reaction was "we want unittest because we want structure", and your reaction was "yes, we need more structure", both of which I took as "I don't really know anything about
py.test" :) Since no one argued *against* structure, I'm not sure where the structure argument comes from. As for not knowing about your "involvement" with py.test, well, how could I? py.test doesn't list an 'author' anywhere I could find, the webpage just says "last edited by Holger", and the debian package came with no CREDITS file other than the 'copyright' file, which doesn't list you ;-P
<br></div></div><br>Credit-+=-mwh-where-credit-is-due--now-please-merge-with-unittest-already<wink>'ly y'rs,<br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
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