I came across an job posting today from the mailing list for my software engineering master’s program at the U of M that showed when you really need testing. I use TDD practices and more and more BDD but I don’t use them everywhere and all the time. To some I am a bad, bad, bad developer and my response is to say come back to reality, buy me lunch, and I’ll hear you out. In theory testing everything is awesome and in theory shipping on time is awesome and in theory testing is more effective and efficient to a project in the long run. But like all rules there are exceptions. I used to keep a business quote years ago on my computer; it is gone now but it went something like “In business, it is always never and never always”. I think I’ve misremembered the quote but I like the idea.
When you have client work that you’ve been cranking on for 5 years or more like I do or ASP.NET sites that are still chugging away after years you know it is not realistic to go back and introduce testing so you have better code coverage, it is just impractical. With legacy systems, one ends up with testing procedures that are outside of the model and normal testing frameworks. Whether it be custom SQL scripts you’ve written to ensure the order totals or that deliveries are made or if its the smell tests you’ve experienced from creating, modifying, and maintaining a codebase for an extended period of time, these are your tests. Obviously that doesn’t extend well and when you have to train in people on the processes that is when the introduction of testing to the code can offer great benefit. Not only will you have the coverage but it also helps anchor the students understanding by having them write the tests and introduce them.
And then there are the cases I have with my current client who has a great business model that is hampered by a less than optimal ASP.NET design. Sure, it has tiers/layers, repositories, some design patterns, broken out classes for every type of functionality possible with the web and internal systems. It has custom exceptions, extenders, modifiers, AJAX of many flavors; yes, it has some cool stuff. But it doesn’t have a central vision and you can tell that multiple outfits have hammered on the codebase because over here a cost is performed this way and over there another. So the design and structure quickly turned to spaghetti with Ragu and I’m in there to uncook the noodles and put them back in the box. But I don’t see how I can add testing to this asp.net site and still get this ship out of the harbor before the school season. And you could say that if the outfits had used testing they wouldn’t be in the place and perhaps that is true; but it is also true that if they followed one vision the project would be better off as well.
Now, if I could rewrite everything using MVC then I’d have coverage all over the place. In honor of NFL training camp I’ll say I’d have a 110% coverage and take it day by day. And before I forget! The job posting that triggered this thought.
A former MSSE graduate, contacted me about software testing positions that he is trying to fill at <company>. Their technology controls those flashing white lights at intersections that signal the approach of emergency vehicles.