Do you need to do unit and integration testing if you already do functional testing? [closed]

Answer 1

One application I was bought in to consult on the FAT (test)ing of consisted of a 21,000 lines switch statement. Most units of functionality were a few dozen to a couple of hundred lines in a case statement. The application was built in several variants, so there were many #ifdef sections of the switch.

It was not designed for unit testing - it was not factored at all.

( It was designed in the sense there was a definite, easy to comprehend architecture - malloc a struct, send the main loop a user message with the pointer to the struct as the lparam and then free it when the message is processed. But form did not follow function, which is the central tenet of good design. )

To add unit testing to new functionality would mean a major break with the pattern; either you would need to put your code somewhere other than the big switch, and double the complexity of the variant selection mechanism, or make a large amount of scaffolding to put the messages in the queue to trigger the new functionality.

So though it's certainly desirable to unit test new functionality, it's not always practical if a system isn't already well factored. Either there's a significant amount of work to refactor the system to allow unit testing, or you end up bench-testing the code and cut and pasting it into the existing framework - and a copy of unit tested code isn't unit tested code.

Answer 2

Unit testing indeed is extra work but it pays off in the long run. Here are the advantages over integration testing :

• you get a regression suite that acts as a safety net in case of refactoring - the same can be said of integration tests, although it can be tough to say if the test covers a piece of code.
• unit tests give an immediate feedback when modifying the code - and this feedback can be very accurate, pointing to the method where the anomaly is.
• those tests are cheap to run : they run very fast (a few seconds typically), without any installation or deployment, just compile and test. So they can be run often.
• it is easy to add a new test to reproduce a problem once it is identified, and it augments the regression suite, or to answer a question ("what happen if this function is not called with a null parameter ...").

There clearly is some overlap between the two, but they are complementary as they both offer advantages.

Now, like any software engineering process, testing has to be taylored according to the project needs.

With a large legacy codebase, legacy in the sense of not unit tested, I would recommend to restrict unit tests to new features added to the code as unit tests can be hard to introduce. In this regard, I can only second (third ?) the recommendation of the "Working Effectively with legacy code" book to help bringing unit testing in an existing codebase.

Answer 3

Yes they are worth it, I am now faster at coding since I started unit testing my code. I spend less time fixing bugs and more time thinking about what my code should do.