Tools and Practices

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.

  • Richard Fennell

    Gill you are right in the end you need code reviews and to remember that the use of any tool or pattern does not guarantee success or failure.

    I would say that I have found using Typemock on legacy code (to provide test isolation via magic so to speak) often helps me to spot the most suitable refactor. In some case this refactor will replace the need for Typemock, but often it allows me to just use Typemock in a more work controlled manner. For example I would now routinely use an MVC pattern for SharePoint webparts (not the MVC framework from Microsoft, just the design pattern). This means I don’t have to use Typemock to Isolate calls out to the SharePoint infrastructure as I can have a production SharePoint model and a manually created test model. However I often find that I end up using Typemock to create this test model (or mock the production one) as it is a more efficient use of my and my customers time.

  • Gil Zilberfeld


    Typemock Isolator is a tool, and I wholeheartedly agree with your last line: it should solve your problems and your customers problem.

    It’s not about making code pretty or design smelly. It’s about real-world solutions.