Unit testing Open Data Protocol Client

Premise

It’s a well-known fact, that communication with an external system is a critical functionality within modern systems. As OData (Open Data Protocol) rises in popularity due to its numerous advantages, more systems choose to expose OData API. Consuming such endpoints is recognized to be extremely easy, as we have a standardized query framework which allows us to get only the data we need from the server. 

Unit testing of such integrations, especially within micro services based system, can introduce a lot of benefits. Those include cost savings, facilitating changes, pushing quality upstream,  to name a few. And, most importantly, it can save a lot of time as broken queries are found before integration or regression tests.

That is why many development engineers tend to consider testing of communication with such system integration tests. Unit test approach for such a functionality would usually consist of checking if our query builder built a correct query. For example:

However, the issue occurs when we want to test method which provides the query string and operates on returned data in particular – how we can mock our web client abstraction.

Arrange

First, let’s consider what elements our puzzle needs.

To mock something like WebClient we would need to provide

1) List of entities backed. In more advanced scenarios we can provide mock for the whole data context.

2) Model of backend data so we can resolve provided url.

What we want to end up with is similar to the following:

Act

First of all, let’s consider our ODataModelHelper class. We need to generate any implementation of IEdmModel so our mock client will be able to resolve entities based on ODataPath. This is relatively simple as we can use the same class, we would use to create actual OData service.

What we want to do in our mock WebClient is following:

1) Find IEdmType associated with our entity type.

2) Create ODataQueryOptions based on provider url and IEdmModel.

3) Apply those options to mocked DataSet.

Let’s translate it to code

 ODataQueryOptions, which is the core of our mock, takes two arguments in constructor. The first one is ODataQueryContext. This class is responsible for generating correct path for correct object type.

The second parameter is HttpRequestMessage. If you are familiar with MVC implementation in .NET, you know, that every HttpMessage is highly dependent on HttpConfiguration. In standard scenario, HttpConfiguration is mostly built based on web.config and during AppStart method, which we don’t have in our mock scenario. This means we have to manually create HttpConfiguration object and supply it to our HttpRequestMessage. 

Assert

As ApplyQueryToEntities is generic, you can use that on any type you need.

This testing approach may also come in handy when you need to test the model builder for your backend API.

As a conclusion, the unit testing of the OData client is a valuable step in making your integrations work to the fullest. As it can be seen, it’s not so difficult to expand your test coverage a little bit further to make it really work for real-life cases. Using this approach you can still use your implementation of repository and provide mock object at a lower level.

Marcin Wojciechowski, Sharepoint Architect/Lead Developer & Project Success Manager at Solidbrain – after hours also a blogger 

Recommended articles
array(0) { }
Avenga: The new global expert in digital transformation
While the uptake of artificial intelligence (AI) technologies in healthcare has traditionally been slower than in other industries, this trend has changed for the better…
Awards and Recognition
Certificates and membership of IT Kontrakt Group
Offer Inquiry
Copyright © 2019 by IT Kontrakt. All Rights Reserved.

By browsing this website you grant your consent to have your personal data which you entered while using the Service, and other parameters recorded in cookie files. stored on the device used for browsing the website, processed for marketing purposes, including profiling, and analytical purposes by “IT KONTRAKT” Sp. Z. o.o., with its registered office in Wrocław, ul. Gwiaździsta 66, 53-413 Wrocław, and Trusted Partners of IT KONTRAKT Sp. z o.o.