Do you concentrate more on unit, integration or acceptance tests?

Question

Most gigs I end up at either have little or no unit tests. Typically what are described as the unit tests are actually integration tests and will be rarely run from the developers machine. I usually start my evangelism by preaching the difference between the two and try to get people to write very focussed unit tests and leave the integration tests for later, i.e. when enough people are writing unit tests that we can "move on" to writing the integration tests. Acceptance or system level tests are usually handled manually by the developer and then by the QA department.

My question is when working outside of an Agile environment, how much effort do you put into unit, integration and acceptance tests and what do you see the most value from?

Answer 1

Very often answer to this question goes to extreme. Like you should have coverage almost 100% or unit tests are stupid....

I believe that you have to find balance.

Use unit tests where there is reasonable doubt that logic of the class can fail. Unit tests must be done on isolated class so it means that you probably need to mock services that class uses. This way you will feel safe to perform refactoring because unit tests will ensure that class still works as expected.

Integration tests are necessary to ensure that you application works at all. You can have number of unit tests but it does not mean that you application will work correctly.

I completely agree with you regarding acceptance test. Do them at the end (of sprint) and partially they must be done manually.

Answer 2

I think you can't mix it up. Each of the tests you have described have a different target.

Unit Test are target to developers. They write a unit test before or parallel to the implementation of a module to ensure it works or all interfaces and requirements are fulfilled.

A integration test is done after development from the test center. You don't test a single module like in a unit test during development. The integration test is covering the interaction between several modules.

A acceptance test often involves the customer himself to check if all requirements are fulfilled and features are implemented like specified.

Answer 3

I try to pound on unit tests from the beginning. I'm not the world's biggest TDD fan, but I really harp on unit tests. I don't think some magic fairy is going to ensure that integration testing is going to pass with flying colors because all of the unit tests work, but it gets pretty darn close.

As for acceptance testing, I'm not even going to look at something until I see the unit tests pass (or fail, if they are supposed to fail). I can't think of many cases that I'd accept a complete lack of unit tests. What if some core lib in the application updates?

Many will argue that unit tests are developer centric, they would be correct. However, a lack of unit tests is an indicator all on its own .. especially if the one doing acceptance tests happens to be a developer :)

Edit:

Integration tests are also important to me. We typically build things to a very tight spec .. when integration tests fail (after previously passing), its a strong indicator of scope creep. When that happens, someone needs to make some noise prior to just fixing it.

Answer 4

I heard the comparison that unit tests are like testing the individual bricks in your wall and functional/integration tests are like testing the entire wall for stability.

The unit tests are necessary for the developers to make sure the classes are doing what they're supposed to.

The functional/integration tests are necessary to make sure you're not missing the "big picture" goal of actually providing certain functions.

So IMHO, both are absolutely necessary and from a ROI perspective it would be a bad idea to leave either out.