4 ms·
I didn't say anything about automated. 99% of the time, I debug using tests. You write the expected output and then fill in the implementation. If you don't ge
by latchkey 4y ago
I didn't say anything about automated.
99% of the time, I debug using tests. You write the expected output and then fill in the implementation. If you don't get what you expect, something is wrong with your code and it is easy to run it in the debugger to figure out what is wrong.
At the end of that, you end up with a test and some code that works.
Other people call this TDD.
- verdverm 4y agomost of the time, I write a small amount of code to work through or debug other's code. It's much easier to be consistent and capture more workflow in a script. Later this can be turned into tests or interfaces. Early on, the script offers much better visibility by typically having access to a debugger
- hitchdev 4y agoWhy not attach debugging tools to the tests?
- rickhanlonii 4y agoYeah we all know what you're talking about, you don't have to explain it. Testing is not the universally correct strategy for every case, and unless you take the time to understand their use case, you're really not in a position to understand the tradeoffs or make value statements about their work.
- latchkey 4y agoIf I had the choice of 'write a tool' or 'write a test'... I'd always pick write a test. Of course, that's me... which is why I asked the question in the first place. I was trying to understand their use case.
- mixedCase 4y agoAs you said it: Of course, that's you. But not everyone walks the same path towards robust coding, let alone coding.
- bastawhiz 4y ago> it is easy to run it in the debugger Yes. They made their own purpose-built debugger. It's a tool that makes it easier to see what the program is doing. Your debugger is no more or less valid than their debugger. It's a tool, and the best tool is the one that enables the programmer to accomplish their goal. And that's what they did.