** 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
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++.
