Exactly what is integration testing - compared with unit

Question

I am starting to use unit testing in my projects, and am writing tests that are testing at the method/function level.

I understand this and it makes sense.

But, what is integration testing? From what i read it moves the scope of testing up to test larger features of an application.

This implies that I write a new test suite to test larger things such as (on an e-commerce site) checkout functionality, user login functionality, basket functionality. So here i would have 3 integration tests written?

Is this correct - if not can someone explain what is meant.

Also, does integration test involve the ui (web application context here) and would employ the likes of selenium to automate. Or is integration testing still at the code level but tying together difference classes and areas of the code.

Solution 1

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.

Solution 2

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.

Solution 3

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.

Comments

[Marty Wallace]

So are these done at the ui level? using selenium say, or is there another test suite written, similar to unit test suite but just broader in scope?

[firelore]

Not necessarily. Think of PaymentService using an external resource, such as a database or a 3rd party API. It could take several seconds to access (on a bad day) or it could just be a long-running process. It is too slow for unit-testing (hence mocking it out), but you still want to test it to make sure it performs properly. That is where integration testing comes in. They are not tests you run repeatedly, usually before performing a release or you have your CI run them.

[Andrew Keeton]

That Martin Fowler article is good. He uses the terms "system/end-to-end test" and "narrow integration test" instead of the ambiguous "integration test."