Skip to content

Testing integration with third party API - Process Tests

Technology

Dec 1, 2020 - 4 minutes read

Process Testing 416X306
Tomasz Synak Senior Software Developer

Professionally, he’s a developer who is constantly trying to ‘think outside the box’ and has a strong interest in backend technologies such as ServiceFabric, NuGet packages, and Microsoft Orleans. He’s currently broadening his knowledge in the area of Domain Driven Design and, most importantly, his favourite pattern—Actor Model. Privately, he has various hobbies such as sailing, water skiing, calisthenics, and mountaineering.

See all Tomasz's posts
1553 Devops Whitepaper News Section 416X300 EN

Share

Why? The need for a new approach

While working on one of the projects, there was a need to verify the results of a complex and long running business process, which has been conducted against external API. The whole process consisted of many HTTP requests, which needed to be done in a very specific order. Since the API was updated frequently, often fails and was ‘moody’, our team needed to verify it manually, usually several times a week, to identify what is not working correctly or what has changed. This was costly. We seeking a solution which would do it quickly, automatically, on-demand and would clearly identify which part is failing.

issue in a nutshell

The issue in a nutshell

What? The requirements

What should be included in the new approach? Let me summarise the main pain points. The solution should:

  • treat the API as a black box,
  • be able to test external API,
  • clearly identify the element of the business process which is not working correctly or API’s endpoint which has changed,
  • do not depend on or use any of the application’s infrastructure (e.g. database),
  • do it automatically, so then it can be incorporated into the build or release pipeline,
  • test the complex and long running business process,
  • test processes in a specific order,
  • testing API should be the only point of truth/state,
  • write tests which reflect and document the business process.

How? The solution

The technology stack in the project I was working on contained one of the most famous and popular unit test frameworks in the .Net world, called xUnit*. Thus, the approach is strongly dependent on that tool.
The main solution, which is the Process Tests approach, contains a few abstractions. These bits and pieces are:

  • IProcess - the interface to identify/mark the business process, which is being under test; it can be re-used in other tests to build more complex scenarios,
  • ProcessTests – a class to orchestrate and launch a list of process tests independently, synchronously and in a specific order,
  • ProcessTestsSettings – tests’ settings taken from a e.g. json configuration file
  • ProcessTestsSharedData – data/state which is shared across different tests
  • SettingsProvider – infrastructure class to serve ProcessTestsSettings
  • Logger – class to log any errors/exceptions thrown during execution

process test

Visualization of dependencies in Process Tests approach as whole

To better understand each part's responsibility, therefore let us analyze it via the example. It would contain two process tests: Logging In User and Updating User Email. Each one of them is a small business process, potentially consisting of several HTTP requests, which together are a more complex one. Updating the user’s email is strongly dependent on logging in the user, thus it should be executed first and its results passed further to the other test, removing the need for arrangements.

visualization of the example

Visualization of the example

Building the solution should start with the implementation of the IProcess interface. It describes the smallest business process, which consists of several HTTP requests. The good separation of each call and additional comments, help document the process (side note: additional comments in yellow).

example of IProcess implementation

Example of IProcess implementation

Once the small processes are implemented, they should be chained together into a more complex one in ProcessTests. This is an orchestrator, responsible for running tests in specific order, managing the tests’ results, and passing any parameters from one test to the other.

example of ProcessTests

Example of ProcessTests

 

The ProcessTests orchestrator also requires a bit of a setup before launching tests. Settings like API url or credentials need to be passed before the first test runs.

example of ProcessTests setup

Example of ProcessTests setup

Of course, this approach is not ideal and most likely will evolve the more it is used, but for now the only drawback I can think of is that the ProcessTests orchestrator can hold one complex business process. For other complex business processes, separate ProcessTests orchestrators would be needed.

Wrapping up

As you can see, with the described approach we can create a suite of tests testing business processes and well document them at the same time. This approach is not dependent on any of the application’s infrastructure, can be incorporated into a build or release pipeline, and does not require any extra arrangement of testing data. It is readable and short, thus easy to maintain and further extend. It can be adjusted to run against external API, as well as API in the memory which we develop.
To check how the described approach works in detail, I strongly encourage you to download the GitHub repository from this link.

Additional notes

The solution needed a bit of adjustment, because the xUnit framework runs tests in parallel and in indeterministic order. The approach requires TestPriorityAttribute and TestPriorityOrderer. The first one helps to set the priority of the test and the second one is responsible for orchestrating the order of the tests. You can read more about these abstractions in the links below:

1553 Devops Whitepaper News Section 416X300 EN
Tomasz Synak Senior Software Developer

Professionally, he’s a developer who is constantly trying to ‘think outside the box’ and has a strong interest in backend technologies such as ServiceFabric, NuGet packages, and Microsoft Orleans. He’s currently broadening his knowledge in the area of Domain Driven Design and, most importantly, his favourite pattern—Actor Model. Privately, he has various hobbies such as sailing, water skiing, calisthenics, and mountaineering.

See all Tomasz's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.