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?

Integration testing is fine to have only at the top level, but it's a good idea to have each layer covered by a unit test, too. — Andy, Jul 10 '20 at 05:41
Does this answer your question? [How should I test the functionality of a function that uses other functions in it?](https://softwareengineering.stackexchange.com/questions/225323/how-should-i-test-the-functionality-of-a-function-that-uses-other-functions-in-i) — gnat, Jul 10 '20 at 06:09
@gnat Thank you for this research. There is indeed some relation between both question. But the one you refer is more about how to test `function1()ˋ and not so much about whether or not it’s worth to test the intermediary steps. Interstingly, none of the duplicates mentioned in that other question addresses this specific point either, which makes this one interesting imho :-) — Christophe, Jul 10 '20 at 10:10
Hi @gnat, I also think that the question is different from the one you shared and does not really address my question — Ryn, Jul 12 '20 at 03:51

score 2 · Accepted Answer · answered Jul 10 '20 at 06:45

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.

score 2 · Answer 2 · answered Jul 10 '20 at 07:08

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.

Should you write integration tests at every level?

2 Answers2