DEV Community: Alex Kondrashov

To mock, or not to mock, that is the question

Alex Kondrashov — Thu, 20 Apr 2023 18:50:15 +0000

TLTR

Mocking is often seen as a default choice when writing tests. Yet it might introduce unnecessary complexety to your system. There are other approaches to manage dependencies in tests.

What is mocking?

Mocking — creating objects that simulate the behaviour of real objects.

Here is how mocking looks in C# in a nutshell (JustMock library):

// Instantiate a new mock
var mockContactRepository = Mock.Create<IContactRepository>();

// Set up the mock and it's return value 
Mock.Arrange(() => mockContactRepository.GetContacts())
  .Returns(new List<Contact>
  {
      new Contact { ContactId = 1 }, new Contact { ContactId = 2 }
  });

// Pass mock as a dependency
var contactManager = new ContactManager(mockContactRepository);

Although it sounds very useful it has to be taken with a pinch of salt.

Shortcomings of mocking

1. Runtime instead of compile-time feedback on changes

If we imagine a test that has Setup() but doesn’t have a return value. When we add a return value, mock doesn’t suggest to add a return type. We only find out about it when running the test.
Here is the example of this shortcoming in C# (Moq library)

public class CarsControllerTests
{

    [Fact]
    public async void testCreateCar()
    {
        var repositoryMock = new Mock<ICarRepository>();

        // No return value set
        repositoryMock.Setup(r => r.Create(car));

        var carsController = new CarsController(repositoryMock.Object);
        var car = new Car() { Name = "BMW", Available = true };
        var result = await controller.Create(car);

        // Use return value on result
        Assert.Equal("BMW", result.Name);
    }
}

The test has built sucessfully but the test will not pass. The reason is no return value set. The controller relies on returned value from the repository.

>> dotnet test

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:01.0309627]     Cars.Tests.CarsControllerTests.testCreateCar [FAIL]
  Failed Cars.Tests.CarsControllerTests.testCreateCar [94 ms]
  Error Message:
   System.NullReferenceException : Object reference not set to an instance of an object.
  Stack Trace:
     at Cars.CarsController.Create(Car car) in /Users/kondrashov/Projects/unit-testing-mocking/src/Cars/Controllers/CarController.cs:line 20
   at Cars.Tests.CarsControllerTests.testCreateCar() in /Users/kondrashov/Projects/unit-testing-mocking/test/Cars.Tests/CarsControllerTests.cs:line 20
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_0(Object state)
Failed!  - Failed:     1, Passed:     0, Skipped:     0, Total:     1, Duration: < 1 ms - Cars.Tests.dll (net7.0)

We get a null reference exception at return car.Id.ToString() To make the test happy we need to use ReturnsAsync() method on our mock:

// Set return value
repositoryMock.Setup(r => r.Create(car))
    .ReturnsAsync(new Car { Id = "1", Name = "BMW", Available = true });

It seems easy and straightforward to change the mock above. But more compex methods become less trivial. The value that this test delivers becomes less with all the time that we spent for it’s maintance.

We would want to know when something broke at the compile-time, instead of runtime.

2. Tight coupling to contracts

Mocking is coupled with contracts by nature. It makes any refactoring harder, because you have to change all realted mocks.

Below I have about 6 different services in my mocking. Refactoring contracts of below services will result in breaking all these mocks. Multiply the breakages by number of test files where you set up mocks.

3. Short System Under Test

System Under Test (SUT) is shorter when we mock a dependency:

A good alternative to such test is an Integration Test with longer SUT:

4. Long-winded set up in each test

A testing framework usually allows you to group your set up. However it’s not always the case as each test often requires a dedicated set up. Below is an example of how each test requires a code to set up mocking:

[TestClass]
public class MyTestClass
{
    private Mock<IMyInterface> _mock;

    [TestInitialize]
    public void Setup()
    {
        _mock = new Mock<IMyInterface>();
    }

    [TestMethod]
    public void Test1()
    {
        _mock.Setup(m => m.MyMethod()).Returns("Hello");
        var result = _mock.Object.MyMethod();
        Assert.AreEqual("Hello", result);
    }

    [TestMethod]
    public void Test2()
    {
        _mock.Setup(m => m.MyMethod()).Returns("World");
        _mock.Setup(m => m.AnotherMethod()).Returns(42);
        var result1 = _mock.Object.MyMethod();
        var result2 = _mock.Object.AnotherMethod();
        Assert.AreEqual("World", result1);
        Assert.AreEqual(42, result2);
    }

    [TestMethod]
    public void Test3()
    {
        _mock.Setup(m => m.MyMethod()).Returns("Goodbye");
        var result = _mock.Object.MyMethod();
        Assert.AreEqual("Goodbye", result);
    }
}

5. You can’t mock just any method

We mock methods. And they have to be public to be eligible for mocking.
Yet certain frameworks allow to you mock private methods using reflection. This is wrong as it break the incapsulation of your design. Example below in Mockito in Java:

when(spy, method(CodeWaithPrivateMethod.class, "doTheGamble", String.class, int.class))
    .withArguments(anyString(), anyInt())
    .thenReturn(true);

What can I do instead of mocking?

1. Integration tests

Write an Integration Test, not a Unit Test. There is more value in writing an integration test instead of a unit test with mocks. We cover more code by writing less tests.

2. End-to-end tests

Integration test might rely on an external dependency. In this case you can’t rely on that dependency since you don’t control it. Write an end-to-end test where you would hit your system as if you were a customer of this system.

3. Stubs

A stub is a small piece of code that takes the place of another component during testing. The benefit of using a stub is that it returns consistent results, making the test easier to write.
If you can’t write an end-to-end test due to dependecies you can’t control — use Stubs. It simialar to mocking, yet it provides a type checking when you introduce changes to your system. Below is an example of a simple stub for a car repository:

public class FakeCarRepository : ICarRepository
{
    public async Task<Car> Create(Car car)
    {
        // Any logic to accomodate for creating a car
        return new Car();
    }

    public async Task<Car> Get(string id)
    {
        // Any logic to accomodate for getting a car
        return new Car();
    }
}

Another advantage the test becomes cleaner. All setup in extracted into a separate file:

[Fact]
public async void testCreateCar()
{
   var car = new Car() { Name = "BMW", Available = true };

   var controller = new CarsController(new FakeCarRepository());
   var createdCar = await controller.Create(car);

   Assert.NotNull(createdCar);
}

Summary

The best approach depends on the specific needs of the project. Consider all trade-offs between mocking and non-mocking. There are other alternatives to mocking out there which you might enjoy.

Resources

Integration Test for Azure Functions and Cosmos DB walkthrough

Alex Kondrashov — Tue, 27 Dec 2022 18:33:53 +0000

To Long To Read

There is a big advantage of running integration tests with a straightforward setup. It hels you finding bugs earlier in the process and it gives you insurance that code works as expected. Follow my guide below to run your integration test for Azure Function and Cosmos DB.

Integration test - is a type of software testing in which the different units, modules or components of a software application are tested as a combined entity.

It's a good pracrice to spin up dependencies locally if possible. You should choose running tests agains local database instead of a remote one. This has couple advantages:

Tests are faster to run locally rather than against a remote database.
You run tests independantly from other developers. The test data from other machines will not impact your database.

System under test

Azure Functions is a cloud service available on-demand that provides all the continually updated infrastructure and resources needed to run your applications. You focus on the code that matters most to you, in the most productive language for you, and Functions handles the rest.

To this example I've put togther an Azure Function. It exposes an endpoint to Create cars:

public class CarFunction
{
    private readonly ICarRepository _carRepository;
    private readonly ILogger<CarFunction> _logger;

    public CarFunction(ICarRepository carRepository, ILogger<CarFunction> logger)
    {
        _carRepository = carRepository ?? throw new ArgumentNullException(nameof(carRepository));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    [FunctionName("CreateCar")]
    public async Task<IActionResult> CreateCar([HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "cars")] CarRequest request, HttpRequest req)
    {
        try
        {
            if (string.IsNullOrWhiteSpace(request.Name))
                return new BadRequestObjectResult("Name is mandatory.");

            var createdCar = await _carService.CreateCar(request);

            return new CreatedResult("/cars/" + createdCar.Id, createdCar);
        }
        catch (Exception ex)
        {
            return new ObjectResult(ex.Message) { StatusCode = 500 };
        }
    }
}

We will be using Cosmos DB to store cars. Here is how the repository looks:

public class CarRepository : ICarRepository
{
    private CosmosClient _cosmosClient;
    private Container _container;

   public CarRepository(IOptions<Configuration> configuration)
    {
        this._cosmosClient = new CosmosClient(configuration.Value.ConnectionString);
        this._container = _cosmosClient.GetContainer("CarDatabase", "Cars");
    }
    public async Task<Car> Create(Car car)
    {
        var itemResponse = await _container.CreateItemAsync(car, new PartitionKey(car.Id));
        return itemResponse.Resource;
    }
}

Since we use function app we have to have Startup.cs:

public class Startup : FunctionsStartup
{
    private const string configurationSection = "Cars:Database";

    protected virtual IConfigurationRoot GetConfigurationRoot(IFunctionsHostBuilder functionsHostBuilder)
    {
        var local = new ConfigurationBuilder()
            .AddJsonFile(Path.Combine(Environment.CurrentDirectory, "local.settings.json"), true, true)
            .AddEnvironmentVariables()
            .Build();
        return local;
    }

    public override void Configure(IFunctionsHostBuilder builder)
    {
        var local = GetConfigurationRoot(builder);
        var config = new ConfigurationBuilder().AddEnvironmentVariables();
        var configurationSection = local.GetSection(configurationSection);
        builder.Services.Configure<Configuration>(configurationSection);
        var configuration = config.Build();
        builder.Services.AddInfrastructure(configuration);
    }
}

Azure Cosmos DB Emulator

We will run our intergation test against local instance of Azure CosmosDB. It's availalble for download here. Here is how it will look once you launch it:

Dependency Injection

The crutual part of integration test setup is to confige dependency injection. You need the following classes for the setup:

TestStartup

We will derived from Startup class to define dependency injection for our test.

public class TestStartup : Startup
{
    protected override IConfigurationRoot GetConfigurationRoot(IFunctionsHostBuilder functionsHostBuilder)
    {
        var currentDirectory = AppDomain.CurrentDomain.BaseDirectory;
        var configuration = new ConfigurationBuilder()
            .SetBasePath(currentDirectory)
            .AddJsonFile("appsettings.json", true, true)
            .AddJsonFile("local.settings.json", true, true)
            .AddEnvironmentVariables()
            .Build();

        return configuration;
      }

      public override void Configure(IFunctionsHostBuilder builder)
      {
          base.Configure(builder);
          builder.Services.AddTransient<CarsFunction>();
      }
  }

Configuration

It's not advisable to store keys and secrets in git repository. For local development we can use local.settings.json to store configuration. Yet we can use appsettings.json to manage configuration. For example, we could use pipeline variables and FileTransform in Azure Pipelines. Here is the example of how can we achieve it.

local.settings.json (shouldn't leave your local machine):

{
  "Cars": {
    "Database": {
      "ConnectionString": "AccountEndpoint=https://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw=="
    }
  }
}

appsettings.json (stays in source control and is enreached by a CI/CD Pipeline)

{
  "Cars": {
    "Database": {
      "ConnectionString": ""
    }
  }
}

TestsInitializer

We want to use a test host for our integration test using TestStartup.

public class TestsInitializer
{
    public TestsInitializer()
    {
        var host = new HostBuilder()
            .ConfigureWebJobs(builder => builder.UseWebJobsStartup(typeof(TestStartup), new WebJobsBuilderContext(), NullLoggerFactory.Instance))
            .Build();

        ServiceProvider = host.Services;
    }

    public IServiceProvider ServiceProvider { get; }
}

We also need to include a Collection definition by deriving from ICollectionFixture class.

[CollectionDefinition(Name)]
public class IntegrationTestsCollection : ICollectionFixture<TestsInitializer>
{
    public const string Name = nameof(IntegrationTestsCollection);
}

Integration Test

We can finally implement our integration test:

[Collection(IntegrationTestsCollection.Name)]
public class CarFunctionTests : IClassFixture<TestStartup>, IAsyncLifetime
{
    private CarFunction _carFunction;
    private readonly TestsInitializer _testsInitializer;
    private readonly CosmosClient _cosmosClient;
    private Container _container;
    private readonly string _carId;

    public CarFunctionTests(TestsInitializer testsInitializer)
    {
        _testsInitializer = testsInitializer;

        var cosmosDatabaseConfiguration = testsInitializer.ServiceProvider.GetService<IOptions<CarConfiguration>>();
        _cosmosClient = new CosmosClient(cosmosDatabaseConfiguration.Value.EndpointUri, cosmosDatabaseConfiguration.Value.PrimaryKey);
        _carFunction = _testsInitializer.ServiceProvider.GetService<CarFunction>();
    }
    [Fact]
    public async void TestCreateCar()
    {
        // Arrange
        var carName = $"BMW - {Guid.NewGuid()}";
        var carRequest = new CarRequest { Name = carName };

        // Act
        var response = await _carFunction.CreateCar(, new DefaultHttpContext().Request);
        var createdResponse = (CreatedResult)_response;
        _carId = (createdResponse.Value as Car).Id;

        // Assert
        Assert.IsType<CreatedResult>(createdResponse);
        Assert.Equal(carName, (createdResponse.Value as Car).Name);
    }
    public async Task InitializeAsync()
    {
        var databaseResponse = await _cosmosClient.CreateDatabaseIfNotExistsAsync("CarDatabase");
        var database = databaseResponse.Database;

        var containerResponse = await database.CreateContainerIfNotExistsAsync("Cars", "/id");
        _container = containerResponse.Container;
    }
    public async Task DisposeAsync()
    {
        await _container.DeleteItemAsync<Car>(_carId, new PartitionKey(_carId));
    }
}

Running the test

We can run our integration test with dotnet test command.

Summary

We've written an integration test for Azure Function and Cosmos DB. We also have used replaceable configuration and configured dependency injection to work for us.

Resources

Is there a better way of writing Integration Tests in using containers .NET?

Alex Kondrashov — Sun, 11 Dec 2022 17:08:52 +0000

Too Long to Read

The cleanest way of writing integration tests is using throwaway containers. TestContainers library helps you to easily manage it.

More…

Managing dependencies for automated tests can be challenging. We could spend hours and manage it manually, or we could automate it and use third party libraries to manage it. In this article I'm searching for a clean and easy way of writing integration test for a modern ASP.NET web application.

System under test

My example exposes a REST API to Create and Get cars:

[HttpPost]
public async Task<CarModel> Create(CarModel model)
{
    using (var connection = await _dbConnectionFactory.CreateConnectionAsync())
    {
        var result = await connection.QueryAsync<string>("INSERT INTO cars (name, available) values (@Name, @Available); SELECT LAST_INSERT_ID();", model);
        var id = result.Single();
        return await Get(id);
    }
}

[HttpGet("{id}")]
public async Task<CarModel> Get(string id)
{
    using (var connection = await _dbConnectionFactory.CreateConnectionAsync())
    {
        var result = await connection.QueryAsync<CarModel>("SELECT id,available,name FROM cars WHERE id=@Id", new { Id = id });
        var model = result.FirstOrDefault();
        return model;
    }
}

You can find the full code here.

Staring with an integration test

🟢 ⚪ ⚪

Integration test - is a type of software testing in which the different units, modules or components of a software application are tested as a combined entity.

How do we know that we write an integration test? We should call all layers of our system from top to bottom in our test: REST API, Controller, Service, Repository and Database.

[Fact]
public async void testCreateCar()
{
    var client = _factory.CreateClient();

    var car = new CarModel { Available = false, Name = "Test Text" };

    var result = await client.PostAsync(_endpoint, new StringContent(JsonConvert.SerializeObject(car), Encoding.UTF8, "application/json"));
    var expectedModel = JsonConvert.DeserializeObject<CarModel>(await result.Content.ReadAsStringAsync());

    var response = await client.GetAsync($"{_endpoint}/{expectedModel.Id}");
    var actualModel = JsonConvert.DeserializeObject<CarModel>(await response.Content.ReadAsStringAsync());

    Assert.Equal(expectedModel.Id, actualModel.Id);
    Assert.Equal(expectedModel.Name, actualModel.Name);
}

If we run REST API and the database prior running the test - it would pass. We have a proof that our system works now! Any integration test is better than the absence of it.

DIY throwaway container using Docker

🟢 🟢 ⚪

What are the problems of the test above? There is a lot of manual labour involved into running it. We need to manage the database and the web application manually.

We would want to spin up dependencies when we start test and tear it down when the execution is over. Docker should be able to help with this. We can lay it down using 3 containers: web application, database and integration container that will run the integration test. All integration between containers is coded in docker-compose.yml:

version: '3'

services:
  integration:
    build: 
      context: .
      dockerfile: Dockerfile.integration
    environment:
      - API_URL=http://web:5001
      - CONNECTION_STRING=Server=db;Database=carsdb;Uid=root;Pwd=password;SslMode=Required;      
    entrypoint: bash /app/wait_for_it.sh web:5001 -t 0 -- dotnet test --logger "console;verbosity=detailed"
    depends_on:
      - web
      - db
  web:
    build: .
    ports: 
      - 5001:5001
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - CONNECTION_STRING=Server=db;Database=carsdb;Uid=root;Pwd=password;SslMode=Required;
    entrypoint: bash /app/wait_for_it.sh db:3306 -t 0 -- dotnet /app/Cars.dll
    depends_on:
      - db
  db:
    platform: linux/x86_64
    image: mysql
    ports:
      - 3307:3306
    # Start the container with a carsdb, and password as the root users password
    environment: 
      - MYSQL_DATABASE=carsdb
      - MYSQL_ROOT_PASSWORD=password
    # Volume the scripts folder over that we setup earlier.
    volumes: 
      - ./Scripts:/docker-entrypoint-initdb.d

The full code is here.

We can now run the integration test via docker-compose up -build -abort-on-container-exit.

TestContainers to manage throwaway containers

🟢 🟢 🟢

Testcontainers for .NET is a library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions. The library is built on top of the .NET Docker remote API and provides a lightweight implementation to support your test environment in all circumstances.

This library gives a clean way to write Integration Tests if we don't want to manage Docker containers ourselves.

We can use a pre-defined MySqlTestcontainer for our web application. The configuration of TestContainer is done via WebApplicationFactory class:

public class IntegrationTestFactory : WebApplicationFactory<Program>, IAsyncLifetime
{
    private readonly TestcontainerDatabase _container;

    public IntegrationTestFactory()
    {
        _container = new TestcontainersBuilder<MySqlTestcontainer>()
            .WithDatabase(new MySqlTestcontainerConfiguration
            {
                Password = "localdevpassword#123",
                Database = "carsdb",
            })
            .WithImage("mysql:latest")
            .WithCleanUp(true)
            .Build();
    }

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.ConfigureTestServices(services =>
        {
            services.RemoveAll<IDbConnectionFactory>();
            services.AddSingleton<IDbConnectionFactory>(_ => new MySqlConnectionFactory(_container.ConnectionString));
        });
    }

    public async Task InitializeAsync()
    {
        await _container.StartAsync();
        await _container.ExecScriptAsync("CREATE TABLE IF NOT EXISTS cars (id SERIAL, name VARCHAR(100), available BOOLEAN)");
    }

    public new async Task DisposeAsync() => await _container.DisposeAsync();
}

Thanks to IAsyncLifetime we can initialize and dispose our database using InitializeAsync() and DisposeAsync() methods.

We now need to use IntegrationTestFactory to get a fake HttpClient:

[Fact]
public async void testCreateCar()
{
    var client = _factory.CreateClient();

    var car = new CarModel { Available = false, Name = "Test Text" };

    var result = await client.PostAsync(_endpoint, new StringContent(JsonConvert.SerializeObject(car), Encoding.UTF8, "application/json"));
    var expectedModel = JsonConvert.DeserializeObject<CarModel>(await result.Content.ReadAsStringAsync());

    var response = await client.GetAsync($"{_endpoint}/{expectedModel.Id}");
    var actualModel = JsonConvert.DeserializeObject<CarModel>(await response.Content.ReadAsStringAsync());

    Assert.Equal(expectedModel.Id, actualModel.Id);
    Assert.Equal(expectedModel.Name, actualModel.Name);
}

This approach allows us to run tests using dotnet test command, which is a plus:

Look at this! We've run our integration test in Docker without having to manually manage containers.

Summary

We have written an integration test and all we need to do to run it is to launch Docker and execute dotnet test command. The web server and the database will be span up for us by TestContainers library. Let me know in the comments below if you see any drawbacks in this.

Resources

Repository with the integration test using Docker Compose.
Repository with the integration test using TestContainers.

Write an Integration test, not a Unit test

Alex Kondrashov — Wed, 04 May 2022 05:32:38 +0000

As a lazy software engineer I want to write code only when necessary. If I happen to write code I want to utilise it as much as possible. If this sounds like you, then let’s look at how Integration tests can allow your code to be more efficient.

Too Long To Read

Write both, Integration and Unit tests, when you have enough time or it’s a critical piece of your system. Write Integration tests first when time is off the essence.

More…

Integration test — is a type of software testing in which the different units, modules or components of a software application are tested as a combined entity.

Unit test proves correct work of one unit only. Whereas an Integration test proves work of more than one unit.

System Under Test

Why is it important to understand what is System Under Test? It will help us define the efficient test.

System under test (SUT) — system that is being tested for correct operation.

It’s normal that Integration test covers wider SUT than a Unit test. Let’s consider the following test:

[Fact]
public async void IntegrationTest()
{
    var client = new HttpClient();
    var model = new Model();

    var result = await client.PostAsync(_url, new StringContent(JsonConvert.SerializeObject(model)));
    var expectedModel = JsonConvert.DeserializeObject<Model>(await result.Content.ReadAsStringAsync());

    var response = await client.GetAsync($"{_url}/{expectedModel.Id}");
    var actualModel = JsonConvert.DeserializeObject<Model>(await result.Content.ReadAsStringAsync());

    Assert.Equal(expectedModel.Id, actualModel.Id);
    Assert.Equal(expectedModel.Name, actualModel.Name);
}

The SUT for the test above is the whole journey of a request in a web service (Controller, Service, Repository and Database). Depending on our assertions we can catch a potential issue in all layers of this web service.

Here is how a Unit test might look for Controller in a web service:

[Fact]
public async void UnitTest()
{
    var serviceMock = new Mock<IService>();
    serviceMock.Setup(p => p.MyServiceMethod()).Returns(true);
    var controller = new MyController(serviceMock);

    var model = new Model();
    var expectedModel = controller.MyControllerMethod(model);

    Assert.Equal(1, expectedModel.Id);
    Assert.Equal("Expected Name", expectedModel.Name);
}

The SUT for the test above is one layer (Controller):

As we can see, Integration tests cover wider SUT than Unit tests with similar amount of code.

Bottom Line

Writing a proper Integration is challenging as it requires initial set up. Yet it pays off with time. Invest your time at the beginning and get a sense of stability about your code later.

Here is how you can ensure you’re writing an Integration test:

🗄️ Use a test instance of database, a test tenant in an external dependency etc.

🖥️ Use test servers instead of mocking and stabbing.

🐳 Use Docker for easier dependency management.

Resources

My example of an Integration test. Refer to the README for instructions of how to run it.
I've discovered a nice Diagram editor: Mermaid digram editor.

OData for ASP.NET Core 6.0 on Mac via command line

Alex Kondrashov — Sat, 22 Jan 2022 16:29:08 +0000

OData is a set of best practices for building and consuming RESTful APIs. ASP.NET Core OData Nuget package provides capabilities for smooth development of OData REST API in .NET application.

I would like to document how I added OData support via the command line since .NET 6.0 includes new structure of Program.cs and I've faced couple challenges there.

Here are the steps that I followed:

Create ASP.NET Core Web API 6.0 application

>> dotnet new webapi -o odata
>> cd odata

Add Entity Framework Core and OData package references

I used EF Core In-Memory Database Provider for simplicity.

>> dotnet add package Microsoft.EntityFrameworkCore.InMemory
>> dotnet add package Microsoft.AspNetCore.Odata

Update `Program.cs`

OData convention model
OData controller
Entity Framework Context

using Microsoft.AspNetCore.OData;
using Microsoft.EntityFrameworkCore;
using Microsoft.OData.Edm;
using Microsoft.OData.ModelBuilder;
using OData.Models;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers();

builder.Services.AddEndpointsApiExplorer();

// Entity Framework Context
builder.Services.AddDbContext<ODataContext>(opt => opt.UseInMemoryDatabase("Cars"));

// OData convention model and OData controller
builder.Services.AddControllers().AddOData(opt => opt.AddRouteComponents("odata", GetEdmModel()).Filter().Select());

var app = builder.Build();

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

IEdmModel GetEdmModel()
{
    var builder = new ODataConventionModelBuilder();
    builder.EntitySet<Car>("Cars");
    return builder.GetEdmModel();
}

Add support for GET requests

We will use EnableQuery annotation to enable GET Requests CarsController.cs. We use a static class DataSource provides the test data. The code for DataSource.GetCars() can be found here

using Microsoft.AspNetCore.OData.Routing.Controllers;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.OData.Query;
using OData.Models;
using OData.Data;

namespace OData.Controllers
{
    public class CarsController : ODataController
    {
        private ODataContext _context;
        private readonly ILogger<CarsController> _logger;

        public CarsController(ODataContext context, ILogger<CarsController> logger) {
            _context = context;
            _logger = logger;

            if (_context.Cars.Count() == 0)
            {
                foreach (var b in DataSource.GetCars())
                {
                    _context.Cars.Add(b);
                }
                _context.SaveChanges();
            }
        }


        [EnableQuery]
        public IActionResult Get()
        {
            return Ok(_context.Cars);
        }

        [EnableQuery]
        public IActionResult Get(int key)
        {
            return Ok(_context.Cars.FirstOrDefault(c => c.Id == key));
        }
    }
}

Run the application and check the result

Good way to prove that OData works is to query all cars where the price is less or equal 50. There is only one car that satisfies that condition.

>> dotnet run
>> curl -X 'GET' 'https://localhost:7005/odata/Cars?$filter=Price le 50' -H 'accept: text/plain' -k

The response should look like the following:

{
    "@odata.context": "https://localhost:7005/odata/$metadata#Cars",
    "value": [
        {
            "Id": 2,
            "Brand": "BMW",
            "Price": 49.99,
            "Model": "3 Series"
        }
    ]
}

Summary

In this example, we looked at adding support for OData to ASP.NET Core Web API application and performed a simple query to prove that the OData requests are coming through. Hope this helped you run your project.

DEV Community: Alex Kondrashov

To mock, or not to mock, that is the question

TLTR

More

Shortcomings of mocking

1. Runtime instead of compile-time feedback on changes

2. Tight coupling to contracts

3. Short System Under Test

4. Long-winded set up in each test

5. You can’t mock just any method

What can I do instead of mocking?

1. Integration tests

2. End-to-end tests

3. Stubs

Summary

Resources

Integration Test for Azure Functions and Cosmos DB walkthrough

To Long To Read

More

System under test

Azure Cosmos DB Emulator

Dependency Injection

TestStartup

Configuration

TestsInitializer

Integration Test

Running the test

Summary

Resources

Is there a better way of writing Integration Tests in using containers .NET?

Too Long to Read

More…

System under test

Staring with an integration test

DIY throwaway container using Docker

TestContainers to manage throwaway containers

Summary

Resources

Write an Integration test, not a Unit test

Too Long To Read

More…

System Under Test

Bottom Line

Resources

OData for ASP.NET Core 6.0 on Mac via command line

Create ASP.NET Core Web API 6.0 application

Add Entity Framework Core and OData package references

Update Program.cs

Add support for GET requests

Run the application and check the result

Summary

Links

Update `Program.cs`