On Tue, 27 Apr 2010 11:16:51 -0400, Barry Warsaw firstname.lastname@example.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