Depending on the capabilities of a debugger, developers might have test failures drop them into an interactive debugger that allows reloads/re-execution of code units.

Debuggers can be I instrumented to do a lot of dev-only logging for you.

I do write tests and assertions, but if those fail, I am dropped into a debugger (if prog is executed interactively), I can immediately inspect the state of my program and more often than not fix the problem on the fly.

I think that, while this might work, the approach to managing state and writing the tests is not ideal. For one, your tests should be fast (ie you should be able to rerun them with almost 0 time penalty and see the results instantly). Second, if it’s easier to stop the flow and look at the state / modify the state than looking at what the state should be via the test setup it’s possible that the abstractions you’re using are not quite right and/or the code is tightly coupled.

> I think that, while this might work, the approach to managing state and writing the tests is not ideal.

I strive to not manage state but to write purely functional code, it makes life so much easier - see your second point as an example :)

I think there is a difference between debugging and using a debugger.

Everyone debugs the software they are building or working on.

Not everyone uses a debugger (depends on language, framework, etc).

IMHO debugging is best done through 1) proper logging 2) metrics 3) proper isolation and software architecture 4) crash early philosophy

This is such egoistic bullshit

> This is such egoistic bullshit

Of course I can be wrong and write bullshit. But why egoistic?

Not OP, but a guess: Implying you are careful, but others aren't.