Debugging all the time isn't fun...
Do you like spending time in the debugger? Personally, I don’t. A lot has to happen to see debugger information, therefore it loads slowly. There are ways to make the debugger faster, but there’s another reason why I don’t like it. Its information is ephemeral. It doesn’t last forever. It is available when I hit the breakpoint and then disappears when I hit “continue”.
So what? Just debug again, right? All of time spent waiting for the debugger to start up, hit a breakpoint, and debug adds up throughout the day. Sure, if I need to remember what a variable was set to, I can copy paste it to a text file so I don’t have to debug again, but I have a better solution: write a test.
Using tests for debugging isn’t usually the way testing is sold to those interested in starting. It’s usually sold as a way to prevent or detect bugs when you’re writing code - new code. What about developers who aren’t always writing new code? How are they supposed to get into testing… they already have bugs to deal with… they know about them fully. They just need a faster way to fix them.
When you start testing as a regular coding practice, you’ll notice that tests don’t have that startup time like the debugger. They don’t have to spin up that temporary web server, open your browser, hit the breakpoint, etc. Add a continuous test runner like NCrunch and you don’t even have to stop to build the project anymore.
I hear you: “but my project is untestable!” For me, that’s where the fun begins. That’s where you start to discover the right refactorings to do. You’re no longer using your eyes to look for code smells, your tests are revealing code smells. This makes the decision to refactor some piece of code much more informed and precise.
Finally, what about all that state information that you get from the debugger?… Well, I have a simple solution for you for that. I’ve used it a lot in my blog posts, but in case you missed it:
Install-Package ToJSON
I put this package up on nuget even though it’s just a simple extension method:
public static class ToJSONExtensionMethod {
public static string ToJSON(this object obj) {
return JsonConvert.SerializeObject(obj, Formatting.Indented,
new JsonSerializerSettings {
NullValueHandling = NullValueHandling.Ignore,
ReferenceLoopHandling = ReferenceLoopHandling.Ignore
});
}
}
It also installs Newtonsoft.JSON if you don’t already have it.
I use statements like _output.WriteLine(object.ToJSON())
all the time to simply log the internal state of an object after running a test. You’ll see them in a lot of my blog posts, so you might already know what I’m talking about.
So, if you’ve always used the debugger to figure out what’s going on, it can be hard to transition to using tests for legacy development. I’m here to say that it’s possible, and it’s worth it. If you need any help, I’ll respond to any email you send me, so sign up now and don’t be shy.
Related Posts:
- New to Testing Time-Dependent Code?… Use NodaTime.Testing!
- Converting DateTimes by Offsets with NodaTime
- Intuitive Testing with Legacy Code
- How to Compare Object Instances in your Unit Tests Quickly and Easily
- Should You Jump into Unit Testing before OOP?
- How Working the ‘Vertical Slice’ Can Fix your Coding Mental Block
- Using TDD to Break Through ‘Paralysis by Analysis’
- Do I Really Have to Unit Test This Method?