4 Common .NET Debugging Mistakes You Should Really Stop Making

4 Common .NET Debugging Mistakes You Should Really Stop Making

Michael Parshin (Senior Consultant at Code Value) wrote an insightful article, in which he lists 4 debugging mistakes .NET devs tend to make over and over again.

We took the liberty to quote the full first mistake according to Michael: debugging instead of unit testing (beautifully explained, by the way), but we strongly recommend reading his full post, explaining all 4.  

1. Debugging the whole system instead of using unit tests

Reproduce, debug, fix, debug, fix, … start the whole system and try to reproduce the buggy behavior, wait until that happens, and then the debugger crashes exactly when you try to check the value of the third element in the array… Sounds familiar? It is a tough and time consuming process, and unfortunately we all go through this vicious cycle, so what could be a solution?

 I believe most of us are familiar with Unit Tests and Test Driven Development concepts, however there are lots of projects out there without even a single test! If your team culture does not allow you to write tests before your write any production code, or even write tests right after you finished writing it – then start writing tests for debugging purposes! When it’s time to fix the next bug, do not step in into debugger, do not prepare some side console app, just open a new test project and start writing unit tests that isolates the issue. Then, you can debug those tests with much less effort and most importantly, the tests you wrote will be yours to keep, and protect you from regressions. When you or your coworker make some unrelated change that re-introduces the same nasty bug all-over again, you’ll know about it!

As you write more tests, you’ll notice that tests are actually valuable in many other ways – they help you express what your code does (or at least, what it ought to do), they serve as documentation for others, showing them how to use your code, and they help verify the solidness of your design.

2. Jumping right into the debugger before checking logs

3. Trying to fix performance related issues without metrics

4. Losing valuable information whenever the application crashes

Read Michael’s very informative and detailed blog post here

Want to dive deeper into the bug fixing process? Watch our webinar: “How to Fix a Bug”.  

 

TOP