Integration Testing: Why Do you Need it

Integration testing, a subject that while it’s very significant, is often neglected because it’s so tedious.

Error localisation, Hard Work and fragility

The easy reason why you need to have a solid foundation of unit tests is that with widening the scope of an evaluation, the attempt goes up disproportionately, while the ability to pinpoint the origin of an error diminishes.

What is worse is that higher-level tests are also more delicate. Move 1 menu to another sub-menu and all tests that used the old button break — at the same time. Now compare this with how frequently UIs are usually tweaked and you get an idea of why having more than the complete necessary quantity of GUI evaluations is a problem.

Another aspect to consider is that when conducting a unit test it’s much easier to find the source of an error than using an integration test. The more code a test covers the tougher it gets to state which part of the covered code contains the mistake.

Rule of thumb: if you can, examine a function on a level as low as possible. Only choose a higher test level if a low-level test is insufficient to show that the work is executed properly.

Abstraction and relevance

Regrettably, very low-level tests have their drawbacks too. As always there’s no free lunch — to keep this analogy cooking a little longer. It hurts to admit: programmers care about device tests — end users do not.

Should you ever saw the V-Model, you may have noticed that there are dedicated tests intended to ensure the end-user requirements are met.

Integration testing can’t be avoided

That having been said, you can find far more than enough cases, where higher degree tests such as integration tests simply can not be averted. Your software doesn’t live in a vacuum and also as soon as you are handling external sources or interfaces, integration tests are mandatory.

To see how quickly you Wind up in the World of integration evaluations contemplate this:

Are you currently changing documents?

Can you get a database?

Are you using services via a network?

If you answer any of those questions with a yes, congratulations, you just won an integration test.

Why high-level tests are so much attempt

In my experience raising a test to higher levels raises attempt. A very simple integration test between an application that you wrote and the database it uses to keep its data requires…

Starting mentioned database,

creating a connection,

authentication,

preparing evaluation information,

running your evaluation,

checking the results

and of course, cleaning up after the tests.

Now envision an end-to-end system evaluation with six solutions involved. Your attempt only went through the roof because today you will need the infrastructure to install those six solutions, connect them, bring them in a deterministic start state, conduct your test, collect the evaluation logs and — well, you get the image, I can go on for one hour with this.

What’s worse is that in that scenario the installation is indeed time-consuming and expensive that you likely have to talk about it with other developers. Plus they probably need slightly different configurations for their tests. If you like a team aren’t very cautious, you violate each other’s evaluations.

Need to test manually

We are now approaching what I believe the core of the integration evaluation problem. Since they’re so hard to set up, the temptation is enormous to create the installation by hand, connect to it, and execute the tests on this setup. Some believe this semi-automatic testing.

My advice: don’t!

This has all kinds of unwanted side effects:

No complete reproducible

Lots of attempts to restore the setup after a disastrous failure

The dreaded”Works on my device”™ issue

It breaks the concept of Continuous Integration

It isn’t accessible for contributors

All in all, this is a situation that you need to avoid at all costs. And if you’re having any doubts, then most of us recognise the”manual testing” is only a fancy way of saying”untested”.

Conclusion

Testing is tough. And it gets tougher the closer the evaluations get to the domain of this end-user. To conquer, ensure your test strategy has a solid foundation of unit tests and add higher-level tests only where unit tests are inadequate. You can not avoid integration evaluations, but you can make your life simpler with virtualisation and an integration test framework. And to end on my diet analogy, I think you’ll agree this method makes integrations tests a heck of a lot easier to consume.