How is unit testing better than just testing the entire output of your application as a whole?

Question

I don't understand how an unit test could possibly benefit. Isn't it sufficient for a tester to test the entire output as a whole rather than doing unit tests?

Thanks.

Answer 1

What you are describing is integration testing. What integration testing will not tell you is which piece of your massive application is not working correctly when your output is no longer correct.

The advantage to unit testing is that you can write a test for each business assumption or algorithm step that you need your program to perform. When someone adds or changes code to your application, you immediately know exactly which step, which piece, and maybe even which line of code is broken when a bug is introduced. The time savings on maintenence for that reason alone makes it worthwhile, but there is an even bigger advantage in that regression bugs cannot be introduced (assuming your tests are running automatically when you build your software). If you fix a bug, and then write a test specifically to catch that bug in the future, there is no way someone could accidentally introduce it again.

The combination of integration testing and unit testing can let you sleep much easier at night, especially when you've checked in a big piece of code that day.

Answer 2

The earlier you catch bugs, the cheaper they are to fix. A bug found during unit testing by the coder is pretty cheap (just fix the darn thing).

A bug found during system or integration testing costs more, since you have to fix it and restart the test cycle.

A bug found by your customer will cost a lot: recoding, retesting, repackaging and so forth. It may also leave a painful boot print on your derriere when you inform management that you didn't catch it during unit testing because you didn't do any, thinking that the system testers would find all the problems :-)

How much money would it cost GM to recall 10,000 cars because the catalytic converter didn't work properly?

Now think of how much it would cost them if they discovered that immediately after those converters were delivered to them, but before they were put into those 10,000 cars.

I think you'll find the latter option to be quite a bit cheaper.

That's one reason why test driven development and continuous integration are (sometimes) a good thing - testing is done all the time.

In addition, unit tests don't check that the program works as a whole, just that each little bit performs as expected. That's often quite a lot more than higher level tests would check.

Answer 3

From my experience:

1. Integration and functional testing tend to be more indicative of the overall quality of the system, than unit test suit is.
2. High level testing (functional, acceptance) is a QA tool.
3. Unit testing is a development tool. Especially in a TDD context, where unit test becomes more of a design implement, rather than that of a quality assurance.
4. As a result of better design, quality of the entire system improves (indirectly).
5. Passing unit test suite is meant to ensure that a single component conforms to the developer's intentions (correctness). Acceptance test is the level that covers validity of the system (i.e. system does what user want it to do).

Summary:

• Unit test is meant as a development tool first, QA tool second.
• Acceptance test is meant as a QA tool.

Answer 4

There is still a need for a certain level of manual testing to be performed but unit testing is used to decrease the number of defects that make it to that stage. Unit testing tests the smallest parts of the system and if they all work the chances of the application as a whole working correctly are increased significantly.

It also assists when adding new features since regression testing can be performed quickly and automatically.