[mtVessel]

When I write code that has multiple, interrelated parts, before I ever run it I step through it in the debugger to verify that my logic is correct, I didn't make any off-by-one errors, library calls return what I expect, etc.

I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run.

Everybody does this, right? Right???

[gjulianm]

> I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run.

I always wrap these statements in a function/if-statement/similar thing that allows me to run the tool in "dry mode" so changes are not done but just logged. It's pretty useful because I can reuse that mode whenever I want without reattaching the debugger and stepping again through everything.

[mtVessel]

Yes, of course, that's the better approach. But you can quickly get bogged down in a ton of extra parameters/environment vars/config scripts/whatever depending on how granular you want that control to be.

My laziness often precludes me from taking that approach until it's clear that it's warranted (but hopefully before I nuke anything critical).

[morelisp]

No, if you use a debugger for this your test suite is too slow or otherwise too difficult to run.