On Tue, 27 Apr 2010 11:16:51 -0400, Barry Warsaw <barry at python.org> wrote:
> 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.
Well, the way I do it for review is brute force: I download the patch,
delete everything except the unit test, apply that, run it, revert,
apply the original patch, run it.
For developing, I generally write the unit test first <grin>, but when
the fix is confined to one file I can just revert the file for testing
the tests while keeping the fixed copy in my edit buffer (or a save file
if I'm feeling paranoid, like when it is a substantial fix). For more
complex fixes I generate separate patch files for the tests and the fix
as a whole, and do a revert-patch-revert-patch dance to test things.
I wonder if it would be better to encourage people to post the unit
tests and the fix as separate patch files.
--
R. David Murray www.bitdance.com
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