Should you write integration tests at every level?

Question

Suppose I have some code as such:

function1() {
    function2()
}
function2() {
    function3()
}
function3() {
    function4()
}
function4() {
    ...
}

Do I have to write integration tests for function1(), function2() and function3()? Or do I only write integration tests for function1(), and unit tests for the other functions?

Answer 1

Technically speaking, if there’s only one integration, you could simply have one integration test. For simple code, like your example, this may prove sufficient.

However, there are plenty of reason that could justify testing the integration at each level. For example:

• there are in reality several integration steps. For example when multiple teams are involved: team A delivers, team B integrates it with its own things, and delivers its end results to team C, for which all this was only the beginning.
• there is a need to correct bug fast. In your example, if function1() fails, you don’t really know what goes wrong. In very complex systems you might then need to write additional tests or logging code to find out where the problem is.
• when you use a test first strategy and write tests to specify what you have to implement (TDD): the intermediary tests then specify what the intermediary components shall achieve.

Answer 2

You should write enough tests so that if, say, function3 breaks it wont take long to realize that the bug is in function3.

It's good to have a test exercising every public interface if for no better reason then it documents how to use the interface. But remember, the main value of tests is that they help you fix things. Write tests that make things easy to fix.

I'm not going to argue over whether you call them unit or integration tests. Just please separate the slow tests from the fast tests. It's nice to not have to run them together every time.