On Tue, 27 Apr 2010 11:16:51 -0400, Barry Warsaw <ba...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com