What is an integration test exactly?

Question

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?

Answer 1

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

Answer 2

integration test, it turns out to be an acceptance test

Obviously.

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.

Answer 3

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.

Answer 4

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.