C#: Manually Create Filter Options in OData

Question

I am trying to manually create an OData query on service method.

Need to create variable in ODataQueryOptions if possible. Filter requirement is on example,Description = "Furniture"

http://localhost/odata/GetProductTypeDto()?$filter=Description eq 'Furniture'

Code:

public async Task<ProductTypeDto> GetProductTypeDto(ODataQueryOptions<ProductTypeDto> odataQueryOptions)
{
    var dto = (IQueryable<ProductTypeDto>)odataQueryOptions.ApplyTo(_productRepository.GetProductTypes)();
    var dtoList = await dto.ToListAsync();
    return dto;
}

_productRepository.GetProductTypes() = // IQueryable which brings out this result {
  new ProductTypeDto {ProductTypeId = 1, Description = "Furniture"},
  new ProductTypeDto {ProductTypeId = 2, Description = "Electronics"},
  new ProductTypeDto {ProductTypeId = 3, Description = "Books"}
}

We are now trying to to create filter Furniture in variable odataQueryOptions, without using API.

Trying to unit test something later,

var actualResult = product.GetProductTypeDto(odataQueryOptions)
Assert.Equals(actualResult.ProductTypeId, 1);
Assert.Equals(actualResult.Description, "Furniture");

It's still not clear, are you asking how to construct the URL with a filter as a string programmatically (without API)? Or are you asking for how to unit test OData endpoints? — Chris Schaller, Sep 12 '20 at 06:33

Chris Schaller · Answer 1 · 2020-09-13T06:26:42.240

update

One of the reasons that it's hard to find specific guidance in this area for OData, is that the URL resolution and OData Deserialization (especially around Patch) is managed for us, or abstracted away. This is good and bad, but it means traditional API endpoint testing in isolation becomes complicated.

For instance a traditional API endpoint will have discrete input arguments and a discrete response argument, however OData arguments are generally wrapped inside generic dictionaries or helper objects that know how to manipulate queries based on their input but are hard to manually inspect. The response from an endpoint is also usually wrapped in a generic negotiated content response wrapper

Units tests should focus on behaviour only

Unit testing involves testing a part of an application in isolation from its infrastructure and dependencies. When you unit test controller logic, only the content of a single action or method is tested, not the behavior of its dependencies or of the framework itself. Unit tests do not detect issues in the interaction between components — that is the purpose of integration testing.

In the case of OData, query options like $filter,$select,$expand... are really part of the framework, as is content negotiation and serialization. These elements require a lot of effort and configuration to mock for the purposes of a traditional unit test, so much so that many tests become indeterminate, when they pass or fail, is this related to the configuration or that actual logic that you were trying to target?

OData endpoints on the controller are generally easier to test using integration testing practises. Specifically for OData this means that you must run an instance of the actual service (either in memory, or deployed locally or to a specific test environment) so you can evaluate endpoints and how they evaluate query epressions through the HTTP pipeline.

You can automate this in VS, or do it in two steps, deploy your API to a testing location with a prepared database and then execute test scripts against it, either as VS unit tests or using external tools like Postman.

There are NuGet packages that can help this process, but it is possible to "self host" your API programatically, so you can hook this up in the unit test init process.

These reasons complicate unit tests against OData endpoint methods directly:

Much of the projection logic ($select/$expand) is evaluated by the EnableQueryAttribute
To construct an instance of ODataQueryOptions requires that the EdmModel is constructed and passed in as well as the Http request to operate on.

So the amount of effort required to setup your mocked QueryOptions is almost the same effort to just run an instance of the service.

If your test routine requires specific and complex manual configuration that basically recreates the API environment almost in full, then there is a high risk of false test results (positivites and negatives) when a test fails, does that mean that the setup for the test was faulty or that the production code you are testing is at fault?

Some people have had success in this area, have a look at this post in the OData Project forum: [feature/netcore] How to unit test with ODataQueryOptions #1352

Also have a look at this guidance, though it is less specific to your needs:
Unit test controller logic in ASP.NET Core

can I run the the api http test through, inmemory, and unit type test environment? — , Sep 13 '20 at 04:55
Yes you can quite easily, that was one of the outcomes from moving to the OWIN pipeline instead of depending on IIS as a host. I've updated my answer to include more reasoning, this post in SO will help specifically with self hosting: https://stackoverflow.com/q/30298458/1690217 — Chris Schaller, Sep 13 '20 at 06:28

C#: Manually Create Filter Options in OData

1 Answers1

update