Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My friends and I have been struggling to classify exactly what is an integration test.

Now, on my way home, I just realised, that every time I try to give a real world example of an integration test, it turns out to be an acceptance test, ie. something that a business person would say out loud that specs out what the system should be delivering.

I checked the Ruby on Rails documentation for their classification of these testing types, and it's now completely thrown me.

Can you give me a short academic description of an integration test with a real world example?

share|improve this question
BTW, when you have a noun phrase ("Me and some friends") you need to be careful which first-person singular you use. Here's the test. Drop the friends and see if it still works. "Me have been struggling" vs "I have been struggling". This test tells you that it's "I and my friends..." And -- to be polite -- we list other first. "My friends and I". Testing is important. – S.Lott Feb 15 '11 at 20:01
Thanks for the guidance S.Lott. – Martin Blore Feb 15 '11 at 20:08
I think S.Lott just gave you a grammar->society integration test. – Jordan Feb 15 '11 at 21:13
up vote 35 down vote accepted

At the moment I like this statement : "It’s not important what you call it, but what it does" made by Gojko Adzic in this article

You really need to specify with the people talking about the tests what you intend to test.

There are a lot of people having different views, depending on what their role is.

For testers a general accepted testmethodology in the Netherlands is T-Map. Tmap makes the following distinction.

  • unit test
  • unit integration test
  • system test
  • system integration test
  • acceptance test (all kinds/levels)
  • functional acceptance test
  • user acceptance test
  • production acceptance test

And than they have more specific kind of tests that can be performed within the above mentioned tests. Look at this word doc for an overview

Wikipedia also has a nice overview

The book the pragmatic programmer says:

  • a unit test is a test that exercises a module
  • integration tests show that the major parts of a system work well together

Looking at these different sources and putting in some of my own experiences and opinions I would start by making distinctions by three categories

  • who does the testing in general
  • what is tested
  • what is the goal of the test

    • Unit test : test logic in classes by programmers to show code level correctness. They should be fast and not dependend on other parts of the system that you don't intend to test
    • Functional acceptance test : test use case scenario's on a limited (specially created) data set done by the test department to show that every specified scenario works as specified.
    • User acceptance test : test use case scenario's on production like data done by representatives of the users to make them formally accept the application
    • Integration test : Test communication paths between different parts of the module done by the test department or by developers to show that all modules work correctly together.

My list above is just a start and a suggestion but I really do think: " "It’s not important what you call it, but what it does"

Hope this helps

share|improve this answer
+1 for emphasizing a pragmatic view. – Péter Török Feb 15 '11 at 20:58
+1 For the "it doesn't matter what you call it". Sadly there is no universal definition of any kind of test. Even the good ol unit-test is a bit variable. Is testing the DOM for a web app considered a unit test? Some say yes, some say no. – Laurent Bourgault-Roy Jan 16 '14 at 20:43
The link to the word doc is not available. – Paul Rougieux Nov 2 '15 at 13:32

integration test, it turns out to be an acceptance test


These two are almost the same thing. But there are some slightly different dimensions to the test definition.

Integration == the system as a whole.

Acceptance == the system as a whole.

The only difference -- and this is subtle -- is the definition of the test cases.

Integration == test cases to test the depth and degree of integration. Does it work for all edge cases and corner cases? Test cases tend to be technical, written by designers and coders.

Acceptance == test cases to exercise just the end-user-focused 80% of the feature set. Not all the edge and corner cases. Test cases tend to be non-technical, written by end-users.

share|improve this answer
Only thing that I would add to this is that integration tests can also test just part of the system, but more than one piece at a time. Any time you are looking for bugs caused by two or more parts of the system working in unison (integrated together), you are integration testing. Integration runs from two components real and everything else mocked, to the entire application suite working together, and may even go so far as checking for integration with other applications (e.g., "How does MS Office work with Internet Explorer?"). – Ethel Evans Feb 15 '11 at 20:03
@Ethel Evans: Good point. The test will still be blurry between integration and acceptance, even if only a portion of the system is involved. The testing occurs at a high-enough level that acceptance and integration will feel similar. – S.Lott Feb 15 '11 at 20:08
Integration tests certainly do not (and probably should not) test "the system as a whole". Anywhere that two or more components are tested together, in particular when testing against external components (database, network etc.) you are doing integration testing. Because of the high costs of "whole system" testing you want to avoid this as much as possible, instead look to do more partial-system integration tests (see Test pyramid – Schneider Feb 27 '14 at 12:44

I personally like to think of an integration test as of a feature test when every component of the system is real, no mock objects.

A real repository, a real database, a real UI. You test specific functionality when the system is fully assembled and is like it is supposed to be when deployed.

share|improve this answer
+1: Real components, integrated. – S.Lott Feb 15 '11 at 19:54
I agree except it doesn't need to be "fully assembled" system. You can (and should) do integration testing with subsets of the full system as this is usually cheaper/easier. – Schneider Feb 27 '14 at 12:48

In my (I admit) little experience, I understood that the word integration can really create misunderstandings: really, it's difficult to find something completely isolated in a system, some elements will need some integration for sure.

Thus, I got accustomed to make the following distinctions:

  • I use unit test to identify, document and stress all the behaviors the class I'm testing is responsible to accomplish.
  • I'm doing integration tests whenever I have a component (maybe more than one) in my system which is having some conversation with another "external" system. (continues below...)
  • I implement an acceptance test to define, document and stress a certain workflow which is expected by the system.

In the integration test definition, by external I meant system which are out of my development range: I cannot change immediately the way they behave, for any reason. It could be a library, a component of the system which cannot be changed (i.e. it is shared with other projects in the company), a dbms, etc. For these tests I need to set up something very similar to the real environment the system will work in: an external system must be initialized and set to a certain state; realistic data must be registered in the db; etc.

Instead, when I'm doing acceptance testing I fake things: I'm working on something different, I'm working on the specifications of the system, not on it's ability to collaborate with external entities.

This really is a narrower view compared to what KeesDijk described earlier, however I suppose the projects I worked on till now were small enough to let me this level of simplification.

share|improve this answer

Integration testing is nothing but checking the connection and correctness of data flow between two of more modules.

For Example: When we compose a mail(one module) and send it to some valid user ID(second module), the integration testing is to check whether the sent mail is there in the sent items.

share|improve this answer
Welcome to Programmers. What does your answer add that hasn't already been provided by the existing answers? Programmers.SE isn't like traditional forums. It focuses on high quality Q&A instead of lots of chatter. Please have a look at the tour page for more information on how the site operates. – GlenH7 Jan 16 '14 at 21:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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