The Difference Between Unit Testing and Integration Testing

** Isolator V7.4.3 is our DeLorean DMC-12 to your inner Marty McFly – Give it a (unit)-test drive now **

Typemock’s Gil Zilberfeld recently wrote an article on “The Difference between Unit Testing and Integration Testing” for Sys-Con.

First things first:
What is a unit test?
A unit test is:

  • Repeatable: You can rerun the same test as many times as you want.
  • Consistent: Every time you run it, you get the same result. (for example: Using threads can produce an inconsistent result)
  • In Memory: It has no “hard” dependencies on anything not in memory (such as file system, databases, network)
  • Fast: It should take less than half a second to run a unit test.
  • Checking one single concern or “use case” in the system: (More than one can make it harder to understand what or where the problem is when the problem arises.)

By breaking any of these guidelines, you increase the chance of developers either not trusting or not believing the test results (due to repeated false failures by the tests), or people not wanting to run the tests at all because they run too slowly.
What is an integration test?
An integration test is any test that can’t be described as a unit test. The different kinds of integration tests (performance tests, system tests, acceptance tests etc.) are not the subject of this piece. Our main concern here is just differentiating unit tests from everything else.
An integration test might:

  • Use system dependent values that change dynamically (such as DateTime.Now, or Environment.MachineName)
  • Create objects of which it has little control (such as threads, random number generators)
  • Reach out to external systems or local machine dependencies (from calling web services to using local configuration files)
  • Test multiple things in the course of one test case (from database integrity, to configurations, to protocols, to system logic, in one go).

Taking those bullets into account, we can say that Integration tests will most likely:

  • Be much slower than unit tests
  • Be much harder or time consuming to recreate and run fully
  • Collecting the test result might be more problematic



Read the full article here.

What do you think about Gil’s article? Is this going to convince you to write more unit tests? If you’re interested in learning more about unit testing, download a 15-day FREE trial of Isolator for .NET or Isolator++ for C++.

  • Simon De Maistre

    Very clear post. Thank you
    I also found an interesting (and a bit funny) point of view here http://arialdomartini.wordpress.com/2011/10/21/unit-tests-lie-thats-why-i-love-them/

  • Uzair

    I am not completely agree with this think.

    1) Unit test or Mock test is use to test single logic where intermediatries call became mock so you can only test you logic. For example if you want to test your logic which you had write in service so you can only test this logic while if there is one or more DAO call you can mock them.

    2) Integration test is where you can test your code where multiple components involve. like service, dao, domain etc. At code level integration testing has nothing to do with (performance tests, system tests, acceptance tests).

  • http://profile.yahoo.com/5KXGYYNTYWNR5DDBSTVAYGIRMI Aman

    I am not satisfy with this answer

  • Pingback: The Difference Between Unit Testing and Integration Testing | QNH - AD Midden linklog

TOP