http://blogs.msdn.com/bmalcolm/atom.xmlCommunity Server2004-05-24T11:41:00Zhttp://blogs.msdn.com/bmalcolm/archive/2004/05/24/140343.aspx2004-05-24T18:41:00Z2004-05-24T18:41:00Z<P>Just a quick introduction:</P> <P>My name's Brian Malcolm, and I'm a developer on the Burton Testing Tools team.</P> <P>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:</P> <P>Ugh!</P> <P>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?</P> <P>But then I soon realized the folly of my ways. It's not about you, oh great programmer, it's about everyone else.</P> <P>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.</P> <P>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?</P> <P>Right.</P> <P>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.</P> <P>And spend less time fixing other people's regressions. </P> <P>And spend more time writing cool new features.</P> <P>B.</P><img src="http://blogs.msdn.com/aggbug.aspx?PostID=140343" width="1" height="1">bmalcolmhttp://blogs.msdn.com/members/bmalcolm.aspx