Some great advice here, but I think it's worth going elementary here and remind people to always first confirm and replicate the bug. Once you've done that it's usually trivial to write a test case. With a test case you can then easily step through and debug at a sufficient level to resolve the issue.
On another, yet similar, note, when resolving the bug don't even try to do it without having sufficient test cases touching the code you're changing. A colleague, and one of the best programmers I've known, coined the term "refucktoring" for when you're refactoring without sufficient test coverage.
I'm only part-time committed to TDD, but pretty much 100% committed to it when it comes to bug fixing. It works!
On a side-note, I'm one of those perverse developers who actually quite enjoy digging into and fixing bugs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some great advice here, but I think it's worth going elementary here and remind people to always first confirm and replicate the bug. Once you've done that it's usually trivial to write a test case. With a test case you can then easily step through and debug at a sufficient level to resolve the issue.
On another, yet similar, note, when resolving the bug don't even try to do it without having sufficient test cases touching the code you're changing. A colleague, and one of the best programmers I've known, coined the term "refucktoring" for when you're refactoring without sufficient test coverage.
I'm only part-time committed to TDD, but pretty much 100% committed to it when it comes to bug fixing. It works!
On a side-note, I'm one of those perverse developers who actually quite enjoy digging into and fixing bugs.