Unit testing vs Integration testing

Though question if someone has to decide between the two, Unit testing and integration testing are not mutually exclusive. Both of them have their merits in the world of automating testing. In this page we will discuss the the advantages and disadvantages of each approach, and will try to provide a recommendation to apply in the Commerce site. There is a good on line article we will use as reference (see reference at bottom of this page) as it makes a good comparison of the two.

Difference in a nutshell 

The distinction between unit testing and integration testing is simple. Unit testing focus on the internal functionality of a single class, while integration testing proves functionality of an entire system, validating that all classes work fine together. In unit testing, when a class depends of another to complete an operation, it's common to use mocking technique to break the dependency and worry only about the class being tested. In integration testing all classes are real implementations and reflects the real work flows of the application.

A brief comparison

Let's compare a few aspects between the two methods. 

Driving the design

Not only in theory, but also for personal experience, we know that unit testing helps to enforce correct designed solutions in the code. Let's be honest, if you have big chunk of code in a single class method, you will find that there is no “clean” way to unit test the core logic. You will wish to go back in time and prevent yourself from writing nasty code. 

That's one reason why unit testing should be done very closely with production code. If it is pushed forward, the poor person in charge of the unit testing code will find himself having to apply refactoring, with the fear of breaking already tested approved shiny functionality. No one wants to face business explaining why application went down for applying simple tests. You can always make your QA team to regress test everything, but that makes it more expensive.

Integration testing does not improve the design, as it doesn't depend of the underlying implementations. This is a pro and con at the same time. By one hand you don't have to worry about refactoring the code just to apply testing, but it won't help improving the code which is also a good thing in terms of maintenance productivity.

Easy to write 

Unit tests are easy to write if they are done side to side with production code. It can get complicated if refactoring is required to make the code unit testable. Integration tests are easy to write in general. It can get complicated depending of the configuration required to prepare the setups required to initialize the test, and to finalize it. For example, if a user story requires interaction with a database, some initial setups will be required to leave the database in a particular state. After the test, another code will need to be run to leave the database as it was before running the test. Depending also of the framework used, coding tests in a web application context (in-container testing) can take a while to learn the first time. Once learning curve is passed, it might get easier.

Confidence in the test 

Unit testing provides a good level of confidence in the application code, but since it doesn't test integration among subsystems, it doesn't give the level of confidence an integration test provides. Integration tests are the best for regression testing. 

Fail troubleshooting 

With any type of x-unit, it will be common for a test to fail. That is the all point of the automated tests. To discover when someone screws up the application, breaking the functionality that a test is 

supposedly covering. 

Tests need to be maintained. It means that if a test fails, someone has to spend sometime figuring out what happened with the test. Why it failed? With unit testing is pretty straightforward. The test points the exact class method that failed. With integration testing you don't know at first glance what was the specific code that failed the entire operation. Therefore, it's more difficult to troubleshoot an integration test when it fails.

Documentation

Unit tests and integration tests are both good ways to document the system. Unit tests document the internal implementations. Integration tests documents user stories.

Speed

Unit tests are definitely faster than integration tests. Since integration tests can interact with databases, web services, application framework stacks, etc, they might become very slow. Usually they are not run as usual as unit tests, which are very common for developers to run to verify nothing got broken during development.

Summary Table

Here's a summary table with our rating of the different aspects commented before. This might be a little subjective as any rating system, but it provides a general overview of both methods. You can see each one has its strengths and weaknesses.

	Unit Testing	Integration Testing
Confidence in the application
Documentation
Driving the design
Easy to write
Fail Troubleshooting
Friendly with Legacy Code
Speed