Why is automated unit testing important?
I’ll be honest, initially I didn’t understand how automated testing can improve the design and quality of my code. Before I actually tried it, my initial reaction was that it adds a ton of overhead to a project to test up front…this was several years ago, you won’t hear me saying that today…another lesson learned.
Recently, I encountered a development team that has zero automated unit tests (or any other types of tests for that matter; integration, regression, etc..), I have attempted to bring them around, however, I’m met with serious pushback from the dev leads and other team members who are used to the current system. When I talk about testing I can see the elders of the team glaze over, and say ‘we’ve tried that’ or ‘we don’t do that here’. This team manages several legacy applications, each of them are at least medium sized, business critical applications. I have to ask myself one question, when changes are made to this legacy codebase, how can they be sure they aren’t destroying other functionality in another subsystem or application? I couldn’t believe there were still teams that don’t see the benefits of automated test harnesses.
So, what are some of the advantages of implementing automated unit tests?
- It promotes good design: you will write less code if you follow a development methodology like test-driven development, or behavior-driven development. You only write code that will make your test pass (all green lights are good), which will stop (or at least limit) the YAGNI coding behavior.
- In a collaborative environment you will have less break-fix issues: By being able to simply open a solution file, update from source control, and run a test harness all within your IDE you can be rest assured that (if your tests are written properly and there is adequate coverage) updates from other developers have not broken any code under test.
- The obvious, test coverage for simple and complex logic: Ever wonder if that complex shipping algorithm is actually performing the logic you were intending it to run? Or, are you sure those simple classes and operations are actually working? You’re sure?
- If done correctly, the tests can serve as your specifications for features: If you have good user stories with appropriate success criteria, you can write a test for each piece of functionality, which will then automatically serve as a good basis for customer and QA acceptance.
The benefits of a testing framework far out way the up front ROI of actually writing the tests. You will be surprised how much your quality improves if done correctly. Convincing you manager and team to get on board seems extremely logical, and in my opinion is a must…especially when you have 0 tests currently.
- There are tons of good resources all over the internets that explain how to get started writing unit tests, here are just a few (if you have more, please leave comment…most are .net centric, but there are tons of resources for other frameworks):
- Definition: http://en.wikipedia.org/wiki/Unit_testing
- Test Framework (.net): http://www.nunit.org/index.php
- How (.net): http://msdn.microsoft.com/en-us/magazine/cc163665.aspx
- How (Java): http://www.basilv.com/psd/blog/2006/how-to-write-good-unit-tests
