We all know the value of automated testing. When I first saw it in college, it was to show how well we can validate our code’s completeness. You got marks off for if your code didn’t pass the professor’s automated tests. It was an automatic C to fail one test. In the working world, I learned about test driven development (TDD) where tests define functionality. Automated tests act as the blueprint of the application, feature, or code change.
But, in recent weeks I’ve learned an even important reason for automated tests. In two separate instances, I was tasked to look why a feature had stopped working. What I had found was both features had code that was lost and clobbered away do to a SVN merge from the feature branch to trunk. When you have multiple teams working concurrently on the same code base, this can happen. Both of these features had stopped working for 2+ years. No one had noticed until now.
So what is automated testing good for? Keeping your code base in check. Had there been automated testing left by the original developers, the next guy checking could see that the merge had cause a problem.