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)
  1. 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)
  • As you define those test types, one thing is absolutely a given. Unit testing each function will never remove the need for integration tests. It’s your unit tests that are arguably of no value as they only test things in complete isolation so do not test the interconnections.
    – David Arno
    Oct 19 '21 at 18:10
  • integration testing is of two or more components together, this is typically but not necessarily tied together with network connections. Think for example a database, how will you make certain things work? Oct 19 '21 at 18:50
  • @ThorbjørnRavnAndersen, a unit test is a test of a functional unit, ie some part of the code that can be run in isolation without side effects. An integration test tests multiple units. If those "components" you describe encapsulate their state then multiple components can be tested as a functional unit and so such tests are still unit tests.
    – David Arno
    Oct 19 '21 at 19:06
  • @DavidArno As always the devil is in the defintion. To me a unit test must be fast - having to set up external components with well-defined states rarely allows this. Oct 19 '21 at 19:29
  • "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 don't think that's a very good definition, nor one as used by many other people. Oct 20 '21 at 5:28

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.


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.

  • 1
    "As for third parties, that may figure into the equation somewhere, but not much. Usually third parties are abstracted away and stubbed." Not when doing integration tests they aren't.
    – David Arno
    Oct 19 '21 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.