This week we finished the first phase of development and testing for one of our new products. One of the missions for the product was to put an emphasis on testing and testability. With this in mind it was a requirement of all developers to write an extensive suite of automated unit tests. This is the first time unit testing was required; as a result it is the first time one of our in-house products had a unit test suite created on the development side. In the past, a large part of QA testing focus was spent creating what I would classify as unit tests instead of focusing more on QA tests. As a result the amount of time a product would need in QA would be extended because it would be necessary to test every property, method and event to make sure all the basic core functionality was working instead of being able to focus more on integration testing.
Part of the past problem we faced in QA was having code delivered to us without being able to test effectively because the core functionality was not working. This time, when the code for the first phase was handed off to me the results of unit testing were evident. Everything that was supposed to work worked and I was able to focus on testing the delivered code as a whole instead of focusing my efforts on each of the individual parts. Not only was the delivered code in good shape, but anytime there were fixes for bugs reported during testing, we knew a usable build would be returned.
Since I served double-duty during the first phase of the project, I too was responsible for creating my own unit tests for the code I was responsible for. No doubt writing unit tests takes a long time; in some cases longer than it takes to actually write the code. But as a developer I found the existence of the tests to be a tremendous help. Anytime I needed to make a change, or needed to debug a problem, the unit tests would were there to run. By creating these tests, I gained confidence in my code and knew it was working and ready to be sent to QA for testing.
One of the main complaints I’ve heard about not creating unit tests is the time it takes to create them, but they actually ended up saving us a bunch of time. Not only did the developers know instantaneously if they broke their code, they also knew if their code changes impacted other areas of the product. And when the code was ready to hand over to QA, it was ready to be tested. The results of all the unit tests could be provided and the QA team didn't need to spend a lot of extra time testing the small parts of the project. Instead, they could focus on the project as a whole.
From what I experienced as a developer and tester, there is no doubt creating unit tests are worth the extra time and effort and do, in fact, save a lot of time in the end.
posted @ Monday, December 13, 2004 5:08 PM