E2E Testing vs. Integration Testing

Although developing software is challenging, there are some key solutions that can help you in such a demanding environment.

One of them is knowing what and when to test. So today, I want to tell you about the roles of E2E and integration tests in the development cycle, what the differences are, and how you can use them to elevate quality.

What’s integration testing and why should you care about it?

You can think about making a new car as an analogy for software development. A car’s engine consists of many smaller parts that are checked by their own manufacturers to ensure that they are not faulty, and so are the components of our applications after they are written by developers.

After the parts are put together and you have an engine, the next step to take is to check if it was assembled correctly and that it is actually working before we put it in the car. This is when integration testing plays the first fiddle.

To put it simply, integration testing is a process to make sure that the parts of the application work as they are meant to after they are put together. It’s a very important step because the places where data transmission occurs are commonly the places where the bugs occur as well.

One of the reasons for this is the fact that just because one part of the system sends out the information doesn’t mean that another part of the application is ready to receive it or that the structure of that message is what is expected.

Pros of integration testing

Adjusting to requirement changes

In an agile approach to developing applications, it's common for requirements to change, even if some of the features have already been implemented according to the initial agreements. It enables both the development team and the business behind it to adjust their methods and product according to the current situation. Thanks to that, it’s possible to fulfill the end user’s needs faster and pivot the direction of development in the world of fast-growing startups.

However, with these unquestionable benefits also comes a risk. It’s the risk of inconsistency which is a straightforward result of requirements being changed on the go.

As a result, changes need to be implemented not only to future application code, but there’s also a need to correct the already existing features. Integration tests ensure that such dynamic changes are not only possible, but it also vastly reduces the risk of doing so.

It will bring the business a lot of value to have integration tests as a test suite ready to be executed manually or simply as automated tests preventing you from committing changes that are incompatible.

Proper controlling modules in microservices

For quite some time, the popularity of using microservices has been rising in software development. Instead of building huge, multi-purpose monoliths, investors rather tend to build and ship their products fast so they can become profitable as soon as possible, and to do that they use external help. External microservices can provide additional functionalities to your application without the need to develop them on your own.

However, the word external also means that you are somewhat reliant on it. Such an external provider might need to implement some changes to how their product works and how it communicates with your application. Modifications like that are not always properly communicated in advance, and proper integration tests might catch any errors and inform you about them fast enough to react and adapt quickly to them.

Testing how a part of the code behaves in connection with parts of the code written by another developer or in another context

These days, applications are mostly coded by teams of at least several developers. The bigger the applications, the more people work on them. Every person has their own style of writing code, their own assumptions, and may interpret feature requirements in their own way.

That’s why even though separate components may work perfectly on their own, it might not be the case when interacting with each other. Do yourself a favor and use this chance to ensure that there are no problems with input/output data early on.

Cons of integration testing

A need for a proper setup of environment, tools, and data

Integration tests performed early in the development cycle very often require a proper setup of environment, tools, and data for the sake of these tests. Preparing such an environment and test data might mean using mocking/stubs, which might give a false feeling of safety and may not cover problems that may occur when real data comes into play.

Imagine a situation when you have a piece of a feature and want to have integration tests ready for it as soon as possible, even though some other parts of the application that it depends on are not there yet. You can deal with such situations by, e.g., stubbing or mocking data and responses that your feature requires and expects from other parts of the app.

However, as we’ve seen earlier, the requirements might change during development and so mocks/stubs can become obsolete, which we may not be aware of. It’s an additional piece of complexity that we need to keep in mind when navigating this requirements-feature-tests triangle.

What is E2E testing?

E2E or End-To-End testing, as the name may suggest, is a “type of testing in which business processes are tested from start to finish under production-like circumstances” (International Software Testing Qualifications Board). It is sometimes wrongly interpreted as exhaustive testing of all features in the application, but in fact its purpose is to simulate the software usage of a real user.

Pros of E2E testing

Simulating the usage of the most critical features that users would use

End-To-End tests are as close to the real users as possible without actually involving them in testing. It means that E2E tests might catch issues that were, for some reason, missed in the earlier stages and will make sure that the most commonly used and the most crucial features (from a business perspective) are always operational and the planned user experience is maintained.

E2E is great as one of the last steps before releases

Results of such tests indicate if the various levels of the application are working as expected on a larger scale than integration tests. For preparing and executing E2E tests, quite a lot of time is often required, and that’s why they are usually not meant to be run after each developer commits.

Instead, they are commonly used as the last step before releasing new changes to the production environment, as a night watch being run every night so that the development team can see the overall application status or after major changes that might’ve introduced bugs to already checked and working functionalities.

Cons of E2E testing

Takes a lot of time to prepare a reliable test environment and to execute

Various unit, integration, and simply feature tests are essential and have their own purpose. Their advantage is that they can be introduced into the project early on and that their execution is relatively fast, but that’s not the case for End-To-End tests.

Actually, they are on the other end of the spectrum. Implementing and executing E2E tests requires the tested system to be at least partially functional so we can simulate the behavior of the end user. Users should be able to get access to the system (register or log in) and perform some actions resulting in achieving some value for them.

It is strongly recommended to conduct this testing phase in an environment similar to the production one. It should not cause any additional delays, should have all data and functionalities in place, and it should be fully operational without unexpected downtimes. Fulfilling all these demands can be time-consuming and may require running the E2E tests at a very specific time, e.g., after working hours.

Coming back to E2E testing vs. integration testing

Which one to choose and which one is better? The answers to these questions are kinda evasive because, as you can see, these two testing methodologies are noticeably different from each other and have distinct purposes. They are both just mere tools in your hands, and it’s your decision whether and how to use them to increase quality in your project. They can either be burdensome to create and maintain or bring a massive amount of value depending on their usage.