We’ve all long since gotten used to third-party services within apps and platforms we use on a daily basis, and we don’t even notice them. Through an API, third-party services can be integrated with any other service to add a larger set of functions – like logging into cooking websites with Facebook, or getting bank information to get an online mortgage. These truly can be used in everything from entertainment to fintech. Fintech, by the way, is what we would like to talk about in the first place, considering how much we have worked in the financial field. We’ve gathered one or two useful bits of info over the years.

As we’ve said, third-party services guarantee extended functionality and flawless functioning without overburdening the main product and making it too complicated. It’s safe to say that these are supporting services. They help major services check the data provided by users and their reliability. In fintech, it can be banks or other institutions that carry information about private persons or legal bodies, exchange-rate data used in e-commerce, or money transfers.

Third-Party Services: A Short Guide

Let’s look at how these services work. For instance, we have a mortgage platform. Users register by providing their personal data – name and surname, date of birth, income, and other relevant information. The platform sends a request to the third-party service it’s integrated with to confirm the data it’s received. The third-party service – in this case, it might be a bank – has information about the user such as their credit history, possibly their criminal record, etc., and provides it to the platform. Here, we see how the third-party service helps the platform recognize imposters or simply provide a better mortgage estimate to a particular user.

At the same time, all this data doesn’t have to be stored on the platform. You store only the data you’ve requested. But at the same time, you have a large pool of data for further searches if you need it. This is why they’re called third-party services – they are the third side of your client-service relationship.

Testing Third-Party Service Integration

Before we connect our platform to a third-party API, we need to see if it plays well with whatever service we’re providing. We need to make sure they understand each other well, and data is represented adequately. But if it’s a third-party service, why do we need to test it?

Testing Data Interpretation

What we really have to test is the integration of the third-party service, or rather the data we get from it. Since we’re going to use it with our own product, we don’t want it to mess up our business. Most importantly, we should test whether the data is interpreted correctly and whether it’s being adequately processed. We need to be sure that the data is being converted to the necessary format and correctly delivered – for instance, if the amount that represents income is shown in the income field, or the calculation run correctly.

It can get especially tricky when it comes to fintech products, as the services have to deal with a lot of numbers. You don’t want your product to mix up someone’s income with an outstanding debt. The whole product and the result of its work depends on the interpretation of data. And this is why testing of the third-party services is so important.

Lacks of Standard Testing

Okay, we’ve established the importance of third-party service testing. But how do we do it? For once, banks, agencies, tax offices and most other financial institutions have already taken care of it. For an extra fee, they can test their services with yours and provide you with the test results.

At this point, you may think that there’s no use in continuing reading this article, right? After all, you can just buy the test results and call it quits. It’s cheap, and less cumbersome.

But the problem is that third-party services can only give you standard testing data. They’re obviously not diverse enough to answer to all the potential search queries. There can be billions of them, but third-party services can’t even give you a couple of hundred.

They love to keep it simple. For instance, test data shows you that if you look for a condo under $700, the third-party service will show you a corresponding list of possibilities. But what if you look for something more exotic, like a bungalow? And if the prices are between $600 and $2000? The third-party service doesn’t include variables like these in their results. What we get is a standard accommodation type at an average price, and that’s it. They’re not configurable. We can’t manipulate them in any way. And this is obviously not enough to test a product.

The Pitfalls of Taking Testing Into Your Own Hands

At this point, it’s clear that we have to test the service using our own resources. There’s just no use in spending money on the test data that third-party services offer. It’s easier to create a test on our own, so we can add any data we want and manipulate it in a way that suits us. This way, we can cover all kinds of enquiries, like price range, type of property, average market price for rent or exchange rate, and so on.

To test how well your product is integrated with the third-party service, you can input different data and see whether the third-party service provides a correct response (or if your product correctly interprets the service’s response). However, this doesn’t resolve the problem of every enquiry being costly. The truth is, using third-party data is quite expensive, as every request sent to them costs a certain amount of money. And you can only imagine how many enquiries you have to send to test all the possible answers you might get from the service!

As you can see, testing may be the most expensive part of the product. So, how do you test your product in a way that allows you to manipulate input data, but without paying all the money in the world?

The Solution to the Testing Problem

Worry not! There is indeed a way to get the test data you need instead of the average results you’ll get from a third-party service. Try a mock service – an imitation of a third-party service. So, it basically looks like a duck, quacks like a duck, but isn’t the actual duck. ConfluenceWe’ve all long since gotten used to third-party services within apps and platforms we use on a daily basis, and we don’t even notice them. Through an API, third-party services can be integrated with any other service to add a larger set of functions – like logging into cooking websites with Facebook, or getting bank information to get an online mortgage. These truly can be used in everything from entertainment to fintech. Fintech, by the way, is what we would like to talk about in the first place, considering how much we have worked in the financial field. We’ve gathered one or two useful bits of info over the years.

As we’ve said, third-party services guarantee extended functionality and flawless functioning without overburdening the main product and making it too complicated. It’s safe to say that these are supporting services. They help major services check the data provided by users and their reliability. In fintech, it can be banks or other institutions that carry information about private persons or legal bodies, exchange-rate data used in e-commerce, or money transfers.

Third-Party Services: A Short Guide

Let’s look at how these services work. For instance, we have a mortgage platform. Users register by providing their personal data – name and surname, date of birth, income, and other relevant information. The platform sends a request to the third-party service it’s integrated with to confirm the data it’s received. The third-party service – in this case, it might be a bank – has information about the user such as their credit history, possibly their criminal record, etc., and provides it to the platform. Here, we see how the third-party service helps the platform recognize imposters or simply provide a better mortgage estimate to a particular user.

At the same time, all this data doesn’t have to be stored on the platform. You store only the data you’ve requested. But at the same time, you have a large pool of data for further searches if you need it. This is why they’re called third-party services – they are the third side of your client-service relationship.

Testing Third-Party Service Integration

Before we connect our platform to a third-party API, we need to see if it plays well with whatever service we’re providing. We need to make sure they understand each other well, and data is represented adequately. But if it’s a third-party service, why do we need to test it?

Testing Data Interpretation

What we really have to test is the integration of the third-party service, or rather the data we get from it. Since we’re going to use it with our own product, we don’t want it to mess up our business. Most importantly, we should test whether the data is interpreted correctly and whether it’s being adequately processed. We need to be sure that the data is being converted to the necessary format and correctly delivered – for instance, if the amount that represents income is shown in the income field, or the calculation run correctly.

It can get especially tricky when it comes to fintech products, as the services have to deal with a lot of numbers. You don’t want your product to mix up someone’s income with an outstanding debt. The whole product and the result of its work depends on the interpretation of data. And this is why testing of the third-party services is so important.

Lacks of Standard Testing

Okay, we’ve established the importance of third-party service testing. But how do we do it? For once, banks, agencies, tax offices and most other financial institutions have already taken care of it. For an extra fee, they can test their services with yours and provide you with the test results.

At this point, you may think that there’s no use in continuing reading this article, right? After all, you can just buy the test results and call it quits. It’s cheap, and less cumbersome.

But the problem is that third-party services can only give you standard testing data. They’re obviously not diverse enough to answer to all the potential search queries. There can be billions of them, but third-party services can’t even give you a couple of hundred.

They love to keep it simple. For instance, test data shows you that if you look for a condo under $700, the third-party service will show you a corresponding list of possibilities. But what if you look for something more exotic, like a bungalow? And if the prices are between $600 and $2000? The third-party service doesn’t include variables like these in their results. What we get is a standard accommodation type at an average price, and that’s it. They’re not configurable. We can’t manipulate them in any way. And this is obviously not enough to test a product.

The Pitfalls of Taking Testing Into Your Own Hands

At this point, it’s clear that we have to test the service using our own resources. There’s just no use in spending money on the test data that third-party services offer. It’s easier to create a test on our own, so we can add any data we want and manipulate it in a way that suits us. This way, we can cover all kinds of enquiries, like price range, type of property, average market price for rent or exchange rate, and so on.

To test how well your product is integrated with the third-party service, you can input different data and see whether the third-party service provides a correct response (or if your product correctly interprets the service’s response). However, this doesn’t resolve the problem of every enquiry being costly. The truth is, using third-party data is quite expensive, as every request sent to them costs a certain amount of money. And you can only imagine how many enquiries you have to send to test all the possible answers you might get from the service!

As you can see, testing may be the most expensive part of the product. So, how do you test your product in a way that allows you to manipulate input data, but without paying all the money in the world?

The Solution to the Testing Problem

Worry not! There is indeed a way to get the test data you need instead of the average results you’ll get from a third-party service. Try a mock service – an imitation of a third-party service. So, it basically looks like a duck, quacks like a duck, but isn’t the actual duck. (Confluence)[https://docs.atlassian.com/atlassian-confluence/REST/6.6.0/], for instance, has an API that stores “fake” data . We use a mock service that our own backend developers wrote for us and enter our data manually. The data you get from the mock is saved in a json file. For instance, Screen 1 shows data about a certain user, while Screen 2 shows potential data on a building, like in the example above.

The method of testing integration using mock data has pros and cons.

Pros:

• Data variability, as opposed to standard test data.
• Independence from third parties – you can’t test services connected with banks outside of their opening hours.
• A greater number of possible test scenarios.
• Less dependency on testers from developers

Cons:

• Artificial environment – hard to predict all of the possible situations that may arise in real life; higher chances of missing something.
• Pesticide paradox – by using the same tests and same data again and again, developers won’t be able to recover bugs, and using new data every time is too cumbersome.
• 500 error – when entering data that aren’t in the mock service, developers will get errors, as it’s rather hard to create all possible answers manually.
• Database maintenance – maintaining your own database gets harder as the database grows.

Make Your Own

To create your own mock test, create a new development environment. Then, install libraries. A mock library – it will replace parts of your system with mock objects. The nose library will make the testing easier. The request libraries will significantly simplify HTTP calls.

Before beginning the tests, be sure to know what to expect from your fake API. First and foremost, the API you’re working with should properly respond when you send it a request. Also, check the structure of the data in the response. Your next assumption is that you will know what the expected data will look like. At this point, you see that the API endpoint is functioning well.

You can write a nose test to confirm the server’s future life and see if the server returns an OK response. Now, run the test and see how it works.

Testing Tips

As you see, there is a way out of the dead end that is efficient and cost-effective. You don’t have to settle for cheap standard tests that don’t help much, and you don’t have to waste money on costly tests that use third-party data for every test inquiry. As soon as you go through a couple of test runs and get a hold of how it goes. However, we still have a couple of recommendations you should consider when you use mock data for testing third-party services.

• Use a separate server for this data, so you can only reach out to your mock data and it doesn’t get mixed up with real data. Running tests with a separate server will also save your users’ data from any possible corruption or security breaches.
• When setting up the service, make sure it always responds to the server it usually works with. For instance, synchronize their deployment. If you introduce changes to the mock server, dev.mock, the third-party server, dev, should be getting the same updates. Otherwise, it won’t be possible to test the way the data is transferred and interpreted.
• Take into account variables like languages, browsers, and environments. To do so, know your users. Think like they do. What gadgets do they use, what languages do they speak, what money do they pay with? Leaving out even one tiny detail may make your test results unusable.

It’s no wonder that they say, “If you want something done right, do it yourself.” Of course, third-party services can make your life and your platform’s work easier, but only if you as the product owner use them correctly. This is also true when it comes to testing third-party integration. There’s no way around this step, so it’s crucial to find the most efficient way to do it. In some cases, maybe even buying test results from the service itself will suffice. But by doing the testing yourself, you can be confident in the results you get. Using mock data enables you to get the most realistic test results, as it gives you more freedom and more variables than standard test data from a service. Either way, you have several options. So choose wisely!

This article about Testing Third-Party Integration Using Mock Data is written by Serhii Bolilyi - QA Engineer. Originally posted on Django Stars blog.