News »Browse Articles »
The benefits of automated unit testing
0
The benefits of automated unit testing
Introduction
Writing software is very difficult. Writing bug-free software all the time is virtually impossible. There are many reasons why this is so; anyone who has written an untrivial piece of software knows how easily a human can miss a tiny detail, and how the slightest of omissions can cause a most spectacular crash, most likely at the most awkward moment.
Unfortunately, the task of writing software promises to be no easier in the future. While software technologies do advance, so does the complexity of the software we write. There is no magical trick in sight in the foreseeable future that would make writing bug-free software simple and straightforward. Still, not all hope is lost - there are some things we can do to substantially improve the quality of software we write.
Ad-hoc Testing
The development of new features to a software product goes in phases. No matter what the methodology, the developer usually starts with the requirements, proceeds to design, then writes the code, debugs it, and finally checks the code into the source code version control system. At this point, the feature is considered done. But how does the developer know that the code actually works?
In many smaller companies and companies that are not really software houses but still develop software for their own use, the developer spends a day or so testing the feature, simply running the application and trying out the functionality with different inputs while observing that the outputs come out as designed. After having completed this testing, the developer has some confidence in that the code works the way it is supposed to. But every developer who has ever written code to an actual product knows the nagging feeling of uncertainty. How good a coverage did the testing have? Did I test every single feature in the application � otherwise how can I be sure that the new code did not accidentally break some other, apparently unrelated, piece of functionality? What if new code written by somebody else two weeks later will adversely affect this feature?
Using developer time for manual ad hoc testing is not a cost effective way of ensuring software quality. Developer time is expensive and is better spent on writing software rather than test-running it ad nauseum. This kind of testing finds out whether the new code affected some other piece of functionality only if the developer tests every single feature in the application. Further, it gives no guarantee whatsoever that the feature still works two months down the road as more features have been added to the system.
Quality Assurance
Some companies have a more or less formal quality assurance process with a team dedicated for testing. The team may have test case scripts that the team goes through and manually tests the software. This activity is carried out after every internal release of the software. Customers will see a new version of the software only after the tests pass and the QA team leader has signed it off.
This kind of testing is better than ad-hoc testing but it is far from optimal. Human testers can and will make mistakes. While hired tester time is cheaper than developer time, the cheapness is offset by the fact that the problems are uncovered relatively late in the development cycle. Every time QA acceptance tests fail, the developers get notified; they fix the problems and give a new version of the software to QA. Time and energy is wasted on communication while the software bounces back and forth between the developers and the QA team. In addition to wasted time and energy, this trashing can have side effects such as creating a �ghetto� mentality in QA personnel.
Quality assurance teams may also have automated testing systems. This is more effective than manual testing, but still is not the optimal situation. Test scripting systems tend to be expensive. Writing good test scripts and maintaining them is something that a tester who was hired for a summer job is not likely able to do. Hiring someone who can write and maintain tests will likely cost as much as hiring a developer in the first place.
Automated Unit Tests
Source:
http://www.codeproject.com/KB/architecture/onunittesting.aspx
Writing software is very difficult. Writing bug-free software all the time is virtually impossible. There are many reasons why this is so; anyone who has written an untrivial piece of software knows how easily a human can miss a tiny detail, and how the slightest of omissions can cause a most spectacular crash, most likely at the most awkward moment.
Unfortunately, the task of writing software promises to be no easier in the future. While software technologies do advance, so does the complexity of the software we write. There is no magical trick in sight in the foreseeable future that would make writing bug-free software simple and straightforward. Still, not all hope is lost - there are some things we can do to substantially improve the quality of software we write.
Ad-hoc Testing
The development of new features to a software product goes in phases. No matter what the methodology, the developer usually starts with the requirements, proceeds to design, then writes the code, debugs it, and finally checks the code into the source code version control system. At this point, the feature is considered done. But how does the developer know that the code actually works?
In many smaller companies and companies that are not really software houses but still develop software for their own use, the developer spends a day or so testing the feature, simply running the application and trying out the functionality with different inputs while observing that the outputs come out as designed. After having completed this testing, the developer has some confidence in that the code works the way it is supposed to. But every developer who has ever written code to an actual product knows the nagging feeling of uncertainty. How good a coverage did the testing have? Did I test every single feature in the application � otherwise how can I be sure that the new code did not accidentally break some other, apparently unrelated, piece of functionality? What if new code written by somebody else two weeks later will adversely affect this feature?
Using developer time for manual ad hoc testing is not a cost effective way of ensuring software quality. Developer time is expensive and is better spent on writing software rather than test-running it ad nauseum. This kind of testing finds out whether the new code affected some other piece of functionality only if the developer tests every single feature in the application. Further, it gives no guarantee whatsoever that the feature still works two months down the road as more features have been added to the system.
Quality Assurance
Some companies have a more or less formal quality assurance process with a team dedicated for testing. The team may have test case scripts that the team goes through and manually tests the software. This activity is carried out after every internal release of the software. Customers will see a new version of the software only after the tests pass and the QA team leader has signed it off.
This kind of testing is better than ad-hoc testing but it is far from optimal. Human testers can and will make mistakes. While hired tester time is cheaper than developer time, the cheapness is offset by the fact that the problems are uncovered relatively late in the development cycle. Every time QA acceptance tests fail, the developers get notified; they fix the problems and give a new version of the software to QA. Time and energy is wasted on communication while the software bounces back and forth between the developers and the QA team. In addition to wasted time and energy, this trashing can have side effects such as creating a �ghetto� mentality in QA personnel.
Quality assurance teams may also have automated testing systems. This is more effective than manual testing, but still is not the optimal situation. Test scripting systems tend to be expensive. Writing good test scripts and maintaining them is something that a tester who was hired for a summer job is not likely able to do. Hiring someone who can write and maintain tests will likely cost as much as hiring a developer in the first place.
Automated Unit Tests
Source:
http://www.codeproject.com/KB/architecture/onunittesting.aspx