Unit Testing with Sitecore OrderCloud SDK in Dot NET

Why unit test if you're using a 3rd-party API client?

When utilizing a third-party API, like one of our OrderCloud clients, unit tests provide several benefits. They help detect integration issues, handle API changes, mitigate dependency risks, facilitate code refactoring and maintenance, and support CI/CD practices. By investing time in writing meaningful unit tests, you can enhance the reliability, stability, and maintainability of your code, even in the presence of external dependencies.

There are a few challenges associated with third-party APIs like OrderCloud that make it a bit more challenging to unit test. Being dependent on external resources with limited control of the API behavior makes it a bit difficult to integrate. On top of that, there also exists maintenance issues that may pop up, like making sure the data returned by that API is consistent through updates. Thankfully there are a few approaches to work around these problems. This blog will detail and explain how to implement those approaches on OrderCloud’s SDK + Catalyst with unit testing-related frameworks like xUnit, Moq, and AutoFixture.

Dependencies:

OrderCloud.SDK

ordercloud-dotnet-catalyst

xUnit

Moq

AutoFixture

Setup

First, let’s create a simple interface and class that uses an OrderCloud SDK client to fetch product data:

Then, create a test class and an xUnit Fact test method of the CreateProductAsync call:

Mocking the OrderCloud Client

The most important way to allow unit testing with a third-party API client is the practice of mocking and stubbing. Mocking and stubbing frameworks, like Moq, would allow third-party API clients to be simulated even in the event that the API is unavailable, removing the issue of having a unit test being externally dependent on an external service.

For the OrderCloud SDK, the client and the resource would be the objects to mock.

Example:

Creating Test Data

Usually, most unit test implementations will hardcode data in-line or create a test class with pre-populated data to check against. However, the problem with this approach is that this becomes very time-consuming for objects that have many properties, such as OrderCloud’s Product model. To work around this, I used the AutoFixture package which automates data population and allows you to randomly generate data as properties in a model. This saves a significant amount of time from having to manually type in data for each property for multiple objects.

Usage Example:

An example of the populated data AutoFixture generates for “expectedProduct” in this test:

In summary, after overcoming the challenges presented with unit testing third-party APIs, I found that the benefits that resulted from the implementation were just as beneficial as unit test implementation for a web app that utilize a first-party API client. Having invested time in writing meaningful unit tests, I’ve found that the reliability, stability, and maintainability of my web applications have seen a significant improvement.