Is the use of third party software and network requests the motivation for integration testing?

Question

I'm wondering if the use of third party software and/or network requests is the motivation for integration testing? For the sake of keeping the code examples minimal, I'll define a unit test as something that tests exactly one function, and an integration test as something that tests two or more functions.

I have in mind a progression like this:

1. An application has only its own function (functions implemented in another module). Would it be fair to say that (short of not knowing how to mock the output of my_first_funcEx1), a unit test on each of the two functions would make integration tests unnecessary in this case?:

    # main
    c = my_first_funcEx1(a, b)
    d = my_second_funcEx1(c)

2. An application uses third party software and/or network requests. Would it be fair to say that (short of doing three unit tests where one of them is on the second function shown below... assuming all relevant inputs/outputs can be mocked) that in this example, integration tests would be indicated where either the first and second function were put in the same integration test; the second and third were put in the same integration test; or all three were put in the same integration test? (Separately the first and third functions could have their own unit tests, but I'm trying to understand the motivation for integration tests in the simplest case):

    # main
    l = my_first_funcEx2(j, k)
    m = third_party_function_call_or_network_request(l)
    n = my_second_funcEx2(m)

Answer 1

The purpose of the integration testing is to catch the myriad of arbitrary decisions made in implementing a boundary contract between code written by different developers. Integration tests is the tool to check that consistent assumptions and understandings happened by both the consumer and implementer of a service contract.

In that respect, I do not see unit testing as written to test exactly and only exactly one function, but more to validate one aspect of functionality. e.g. does the guard clause throw a null exception if I pass a null reference. as well as if I pass in a set of valid data, do I get the correct answer.

Integration tests are about validating that the services that my code calls understand and accept my requests, and provide answers that my calling code correctly understands.

This service may simply be another class in the same project, or it could be a remote service provided over the network. The distinction is that when I am working in this area of work, I am not also thinking about the implementation details of that service, only its service contract. If this applies, integration tests may be appropriate.

Answer 2

Integration testing needs no justification-- it is always done-- if not by you then by your customers. In most cases, an organization will decide to do its own integration testing before release to the public.

The question then becomes-- how early do you start integration testing? Do you test the entire system at once at the end? Probably. Do you test individual components immediately, in pairwise fashion, to make defect analysis easier, and to control project risk? That would cost more. You could also choose something in between. The answer is going to depend on the cost/benefit analysis in your particular situation.

The cost of the testing will depend on whether you automate the integration testing. You don't have to automate it. But in my experience, spending time to automate your integration testing is very cost effective, and in fact gives much more bang for the buck than unit testing.

As for third parties, that may figure into the equation somewhere, but not much. Usually third parties are abstracted away and stubbed.