4 ms·

Neither, I spend more time writing or thinking about tests. When I was earlier in my career I used to insert debug comments, run code, look at output to figure

Neither, I spend more time writing or thinking about tests. When I was earlier in my career I used to insert debug comments, run code, look at output to figure out what was going on. Now, I try to write my tests that will eliminate the need to debug. If I'm trying to fix a bug, the first thing I do is write tests for what should happen if the tests don't already exist and work backwards from there. If you get in a good habit of this, it just becomes natural and with today's toolchains you can re-run tests with a watcher to achieve a real time feedback loop, which is better than a debugger IMO. The plus side is going forward you always know that the code works vs just seeing it work that one time. As your application grows, something may change what the value of the debug statement output and you'll never catch it, but your test will. /old man rant

existencebox 10y ago
I'd shift your statement slightly, "I spend my time Thinking" (elided "about test"), but agree entirely with the thrust of your point. My reason for the truncation is that the thinking isn't just about what tests to write to validate the semantics you want, but what semantics do you even WANT? Happy path may take an hour to figure out, but getting to a point (for a reasonably complex system) where I feel confident that I've enumerated the "perimiter" of the mental model such that there are fewer surprises, gotchas, odd edge cases, usually takes significantly more contemplation of the problem space than modern big-co "DELIVER FEATURES NOW NOW NOW" would often like, certainly more time than spent actually implementing, by and large. (you may sense some bitterness, it is largely because a respected mentor of mine made significant effort to stress to me that if I'm leaning on a debugger, or having to printf a lot, I probably don't UNDERSTAND what's going and and can fall prey to far more severe logical issues; and despite my observation that I became a far more robust engineer utilizing this strategy, it's often hard to incentivise balancing this against simply shipping, especially given the difficulty of empirically justifying "I need a day to think really hard about this problem to make sure it's not subtlety wrong" against the rebuttal of "what's the ROI")
dibanez 10y ago
Agreed. I used to debug large "integration tests". Now with unit testing, I'm only debugging a bit of new code atop a foundation that is regularly unit tested.

existencebox 10y ago

I'd shift your statement slightly, "I spend my time Thinking" (elided "about test"), but agree entirely with the thrust of your point. My reason for the truncation is that the thinking isn't just about what tests to write to validate the semantics you want, but what semantics do you even WANT? Happy path may take an hour to figure out, but getting to a point (for a reasonably complex system) where I feel confident that I've enumerated the "perimiter" of the mental model such that there are fewer surprises, gotchas, odd edge cases, usually takes significantly more contemplation of the problem space than modern big-co "DELIVER FEATURES NOW NOW NOW" would often like, certainly more time than spent actually implementing, by and large. (you may sense some bitterness, it is largely because a respected mentor of mine made significant effort to stress to me that if I'm leaning on a debugger, or having to printf a lot, I probably don't UNDERSTAND what's going and and can fall prey to far more severe logical issues; and despite my observation that I became a far more robust engineer utilizing this strategy, it's often hard to incentivise balancing this against simply shipping, especially given the difficulty of empirically justifying "I need a day to think really hard about this problem to make sure it's not subtlety wrong" against the rebuttal of "what's the ROI")

dibanez 10y ago

Agreed. I used to debug large "integration tests". Now with unit testing, I'm only debugging a bit of new code atop a foundation that is regularly unit tested.