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

Answer 1

Retroactively writing unit tests for legacy code can very often NOT be worth it. Stick with functional tests, and automate them.

Then what we've done is have the guideline that any bug fixes (or new features) must be accompanied by unit tests at least testing the fix. That way you get the project at least going in the right direction.

And I have to agree with Jon Skeet (how could I not?) in recommending "Working Effectively With Legacy Code", it really was a helpful skim/read.

Answer 2

As it happens, I read a paper last night on this very subject. The authors compare projects within four groups at Microsoft and IBM, contrasting, in hindsight, projects which used both unit testing and functional testing and projects which used functional testing alone. To quote the authors:

"The results of the case studies indicate that the preview release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15 to 35% increase in initial development time after adopting TDD."

This indicates that it is certainly worth doing unit testing when you add new functionality to your project.

Answer 3

(I'm assuming that you're using "functional test" to mean a test involving the whole system or application being up and running.)

I would unit test new functionality as I wrote it, for three reasons:

• It helps me get to working code quicker. The turnaround time for "unit test failed, fix code, unit test passed" is generally a lot shorter than "functional test failed, fix code, functional test passed".
• It helps me to design my code in a cleaner way
• It helps me understand my code and what it's meant to be doing when I come to maintain it. If I make a change, it will give me more confidence that I haven't broken anything.

(This includes bug fixes, as suggested by Epaga.)

I would strongly recommend Michael Feathers' "Working Effectively with Legacy Code" to give you tips on how to start unit testing a codebase which wasn't designed for it.

Answer 4

It depends on whether your functional tests are automated or done manually. If it's the latter, then any kind of automated test suite is useful since the cost of running those unit / integration tests is far lower than running manual functional tests. You can show real ROI there. I would recommend starting with writing some integration tests and if time / budget allows in the future, take a look at unit testing then.

Answer 5

You test when you want to know something about something. If you know that your product (system, unit, service, component...) is going to work, then there's no need to test it. If you're uncertain as to whether it will work, you probably have some questions about it. Whether those questions are worth answering is a matter of risk and priorities.

If you're sure that your product will work, and you don't have any questions about it, there is still one question that's worth asking: why don't I have any questions?

---Michael B.

Answer 6

Most people are unaware what automated unit tests are for:

1. To experiment with a new technology
2. To document how to use a part of the code
3. To make sure a dead bug stays dead
4. To allow you to refactor the code
5. To allow you to change any major parts of the code
6. Create a lower watermark below which the quality of your product cannot possibly drop
7. Increase development speed because now, you know that something works (instead of hoping it does until a customer reports a bug).

So if any of these reasons bring you a benefit, automated unit tests are for you. If not, then don't waste your time.