On Apr 27, 2010, at 02:40 PM, exarkun at twistedmatrix.com wrote:
>On 01:38 pm, rdmurray at bitdance.com wrote:
>> 2) have unit tests that fail before the patch and succeed after
>
>This list would make a good addition to one of the cpython development
>pages. If potential contributors could find this information, then
>they'd be much more likely to participate by doing reviews.
It would be kind of cool if there were some best practices for running said
unittest both with and without the patch enabled. Kind of like using #ifdefs
in C but without all the commenting-out-commenting-in error proneness. I
guess you could do something like
if os.getenv('BUG1234'):
# Patch the frobnicator to not bloviate.
Maybe more trouble than it's worth, and not always feasible of course, but I'm
wondering how (or maybe if) people do things this way.
With Bazaar, I often use a loom with two threads - a bottom one that contains
the test that fails, and a top one that contains the fix for the test. It's a
great way to develop a patch, but you lose that once you flatten the code for
review.
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100427/3467ccaf/attachment.pgp>
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