Our new feature, faking DateTime, coming out in the next version of Isolator is creating quite the buzz. For specific examples you can check out Jimmy Bogard’s and Richard Fennel’s reactions. Both question how the ability to test (with a certain tool, that shall remain nameless) affects the ability to design (well).
"Testable code" is a definition that I’m struggling with since I’ve been here. First because Isolator (ok, it slipped) makes everything testable. But when I say "my code is testable", does it mean an actual quality of the code?
If you practice SOLID and DRY you’ll get testable code, which means, you’ll be able to test it with various tools. Is it a good design? It depends. If I use dependency injection for my date and time services, I may be using an unnecessary abstraction, one that will make my code less readable and maintainable. And of course, even working with SOLID and DRY principals but choosing crappy names and when no one reviews my code – I can assure you it’s not going to be readable, nor maintainable. Lousy practices do make bad code, even without tools.
Throughout history we have defined practices based on the technology we have. Cavemen sat around a fire wherever it appeared. Thanks to Johannes Gutenberg, we have set up local schools and libraries, where people come to attain knowledge. And the mobile devices today allowed me to retire my Ghetto-blaster and allow my neighbors to listen to something different than 24-hour marathons of HanselMinutes.
Tools make an impact, whether we like it or not. Today we don’t give a second thought when we refactor some code to a separate class, in a different file, because Resharper does it automatically and correctly. Michael Feathers showed us how to do that (in a book, that’s a tool too), and that became a practice. Would we do it 10 years ago? Without tooling? It was considered a bad practice to write code in many files – Visual Studio wouldn’t handle it!
Practices and tools converge, and lead to better things. We should always challenge our practices, make sure they meet our goals. And if our tools are not good enough? We need to upgrade them as well! Maintainable code is a goal, because it saves time and money over time. What makes maintainable goal? great tools and great practices. Together.
So Richard – you ask if your code stinks? You know how happy I was if using Isolator would be the only metric for that? But it’s not. Let’s do a code review and find out.
