Just a quick introduction:
My name’s Brian Malcolm, and I’m a developer on the Burton Testing Tools team.
I can remember when I first joined this team, and was told that developers would have to write unit tests for their features before they were allowed to check their code in. I can sum up my initial thoughts in one word:
I mean, what a waste of time that I could instead be using to write cool new features! Obviously my code works, otherwise I wouldn’t be checking it in. Why waste time writing unit tests?
But then I soon realized the folly of my ways. It’s not about you, oh great programmer, it’s about everyone else.
You see, if you have robust unit tests for your features, and if you have a policy that says that no one is allowed to check-in code unless that code passes all available unit tests, then you are protected from someone else checking in a change that breaks your code.
Because, let’s face it, when a feature in your code breaks, you’re the one they’re going to call, regardless of who checked in the breaking fix, right?
So, write unit tests. Use code coverage to verify that your unit tests are hitting all of the important areas in your code. Establish a checkin policy using those unit tests so breaking changes don’t get checked in.
And spend less time fixing other people’s regressions.
And spend more time writing cool new features.