3 ms·
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 mak
by mtVessel 5y ago
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 5y ago> 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 5y agoYes, 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 5y agoNo, if you use a debugger for this your test suite is too slow or otherwise too difficult to run.