Exactly what is integration testing - compared with unit

Unit testing is where you are testing your business logic within a class or a piece of code. For example, if you are testing that a particular section of your method should call a repository your unit test will check to make sure that the method of the interface which calls the repository is called the correct number of times that you expect, otherwise it fails the test.

Integration testing on the other hand is testing that the actual service or repository (database) behavior is correct. It is checking that based on data you pass in you retrieve the expected results. This ties in with your unit tests so that you know what data you should retrieve and what it does with that data.

Consider a method like this PerformPayment(double amount, PaymentService service);

An unit test would be a test where you create a mock for the service argument.

An integration test would be a test where you use an actual external service so that you test if that service responds correctly to your input data.

Unit tests are tests that the tested code is inside of the actual class. Another dependencies of this class are mocked or ignored, because the focus is test the code inside the class.

Integration tests are tests that involves disk access, application service and/or frameworks from the target application. The integration tests run isolated from another external services.

I will give an example. You have a Spring application and you made a lot of unit tests to guarantee that the business logic is working properly. Perfect. But what kind of tests you have to guarantee:

• Your application service can start
• Your database entity is mapped correctly
• You have all the necessary annotations working as expected
• Your Filter is working properly
• Your API is accepting some kind of data
• Your main feature is really working in the basic scenario
• Your database query is working as expected
• Etc...

This can't be done with unit tests but you, as developer, need to guarantee that all things are working too. This is the objective of integration tests.

The ideal scenario is the integration tests running independent from another external systems that the application use in a production environment. You can accomplish that using Wiremock for Rest calls, a memory database like H2, mocking beans from some specific classes that call external systems, etc.

A little curiosity, Maven have a specific plugin for Integration Tests: the maven failsafe plugin, that execute test classes that the name ends with IT (by default). Example: UserIT.java.

The confusion about what Integration Test means

Some people understand the "integration test" as a test involving the "integration" to other external systems that the currently system use. This kind of tests can only be done in a environment where you have all the systems up and running to attend you. Nothing fake, nothing mocked.

This might be only a naming problem, but we have a lack of tests (what I understand as integration tests) that attends the necessity of the items described above. On contrary, we are jumping for a definition of unit tests (test class only) to a "integration" test (the whole real systems up). So what is in the middle of it if not the integration tests?

You can read more about this confusion on this article by Martin Fowler. He separates the "integration tests" term on two meanings: the "broad" and "narrow" integration tests:

narrow integration tests

• exercise only that portion of the code in my service that talks to a separate service
• uses test doubles of those services, either in process or remote
• thus consist of many narrowly scoped tests, often no larger in scope than a unit test (and usually run with the same test framework that's used for unit tests)

broad integration tests

• require live versions of all services, requiring substantial test environment and network access
• exercise code paths through all services, not just code responsible for interactions

You can get even more details on this article.