I used to never create unit tests for the code I'd write. Why? Deadlines. Get it done, test it, send it to QA, have defects reported, rinse and repeat. I became tired of that so I pressed my boss to give me a little more time in development so that I can create formal unit tests for my code and send stronger code to QA. It took a littler longer to do than I'd hoped, so that I wasn't too thrilled about. However, the results were astounding! All programmers out there, you have to start creating unit tests for your code! NOW!
The application I'm working on takes data in from multiple databases, processes it and writes data back out to the databases. I had to overcome database dependency for my unit tests. Nothing worse than getting a new database instance for development and discover 60 unit tests break.
Second obstacle probably the biggest benefit for development and that was what happens when QA finds a defect? You need to recreate the defect. How long does that take? Minimum a half hour? Sometimes days? To recreate the defect, you need the data they were using. Sure, you can setup your database the way QA says it was, but was it really setup exactly the way they say? Come on, we all have that doubt in the back of our heads because it's bitten us before. What can you possibly do to alleviate this headache? Aren't your unit tests database independent? So, capture the data and make a unit test out of it!
I've had a few occasions when I had a defect that had a simple one liner solution. Out of 230+ unit tests, the fix broke about 40 or more unit test! Would QA catch it? During regression testing, sure! If there were moving on like usual, no, they would have not caught those scenarios.
I'll post my experiences with unit testing and integration into Visual Studio 2008 using Resharper soon.
Here is how to create a simple Database Application Unit Test [CodingCramp.blogspot.com].
No comments:
Post a Comment