When entering a complex project in the TravelTech industry, I am immediately struck by the scale of integration – from booking flights through Kiwi, Duffel and Amadeus, to hotels with Booking or Ratehawk. Every new team member is challenged to understand and manage complex processes. So how do we make sure that every piece of functionality works as intended?

How do you effectively test and document solutions so that new team members can quickly onboard and understand complex integrations? The key tool I have chosen to address these issues is unit tests – not only as a way to verify code, but also as living documentation that speeds up onboarding and supports debugging.

Testing and documenting integration at Traveltech ​

When working on complex integrations in Traveltech, I often encounter a key problem: how to effectively manage the testing and documentation of systems that combine different platforms and vendors.

When we develop such systems, we need to integrate data from a variety of sources – from flight bookings (Kiwi, Duffel, Amadeus, Tripstack) to hotels (Booking, Ratehawk) to parking (Parklot), eSIM (Airalo) and insurance (Allianz). Each of these providers has unique specifications, communication protocols and data formats.

The biggest challenges of integration testing and documentation ​

As the number of integrations increases, further challenges arise. Firstly, each new integration adds an extra level of complexity. Each supplier introduces its own processing rules, requiring the creation of specialised testing procedures. Testing becomes more difficult as the system must correctly handle the various scenarios that can occur depending on the specific vendor.

Another challenge is the complexity of the system. This makes documenting what has been implemented crucial. How can I document the integration in a way that is not only clear and understandable, but also detailed enough to serve as a 'source of truth' during future testing and deployments? In such an environment, the documentation must not only be accurate, but also live, updated with each change to the system.

In such cases, traditional testing and documentation approaches may not be sufficient. More sophisticated methods are needed that not only verify the correctness of the code, but at the same time document the entire process in a way that is understandable and easily accessible to future team members.

A simple solution to complex challenges – integration unit tests ​

These challenges lead to the need to implement an approach that combines testing with documentation – where unit tests become not only a verification tool, but also an essential part of the technical documentation.

Unit tests, usually seen as a tool for validating code, in our approach play an additional role – they become living documentation that supports the onboarding process for new team members.

This enables new people joining the team to quickly understand how the system works and how it has been designed, significantly speeding up the problem-solving process.

Each unit test is like documentation – it clearly states what the expected behaviour of a function or module is, and its name usually describes what exactly is being tested.

TDD (Test-Driven Development) methodology ​

Using the TDD (Test-Driven Development) methodology, we first write tests for new features and only then implement code that meets these tests. In this way, we can be sure that every operating scenario has been thought through and taken into account from the design stage.

What's more, if something changes in the future, such as adding a new supplier, the existing tests will allow us to quickly identify where we need to update.

In practice, this means that our code is always well tested and well documented. When a new person joins the team, they can start by reviewing the unit tests, which allows them to understand how the system works without having to read lengthy and often outdated documentation.

Unit tests become not only a verification of the correctness of the code, but also a guide to the system, significantly reducing the time needed to implement new team members.

This approach also allows us to debug and troubleshoot more easily, as well-written unit tests clearly indicate where the problem may lie when something is not working as expected.

This gives us confidence that our system is running smoothly and that new team members can be quickly and effectively introduced to the project.

What should a good unit test be? ​

A good unit test is the foundation of solid code. To be truly useful both as a verification tool and as documentation, unit tests must meet several key standards.

Above all, such a test should be short and concise – focused on checking one particular aspect of functionality. The more precise and specialised the test is, the easier it is to understand exactly what it is checking and what part of the code it covers.

Another important element is unambiguity – a good unit test should test one piece of functionality in isolation from the rest of the system. That way, if the test fails, it is immediately clear where the problem lies, without having to sift through larger chunks of code.

The name of the test plays a key role in its comprehensibility. The name should be descriptive and clearly indicate what is being tested.

Such a name not only communicates what exactly is being tested, but also gives context regarding what functionality the test is about.

A well-designed unit test is also readable – its structure should be simple and its logic clear. The readability of the test makes it easy for even people who did not create the code to understand its purpose and operation.

Finally, a good unit test should be deterministic – this means that its result should always be the same, regardless of the environment or the moment of execution. Only then can it be relied upon as a tool to verify the correctness of the code.

In summary, a good unit test is one that is concise, unambiguous, well named, readable and deterministic. Such tests not only increase the quality of the code, but also act as valuable documentation, supporting the induction of new team members and helping to debug problems more quickly.

If you are looking for a solution to suit your system, talk to us!