In hindsight, I could have probably solved this issue a lot quicker, but the error was so vague and the fact that CDN changes take some time to propagate, it took me more effort than I wanted. So, here we are, I'm writing this blog post in the hopes of saving you some time. I ran into some connectivity errors when connecting an Azure CDN to an Azure blob storage. But this might also apply to your web apps.

TL;DR: Go to solution

The setup

Our infrastructure setup is straightforward, centred around using Azure Blob Storage to host files like software installers, which are then distributed via Azure CDN to ensure global accessibility with low latency. A custom DNS was integrated with Azure CDN (and an Azure-managed SSL) to provide a branded and easy-to-remember access point for these files. The entire setup, from storage accounts to CDN configurations and custom DNS mapping, was provisioned and managed using Terraform. As a first setup, this is quite straightforward, and the terraform is relatively easy. It validates, plans and applies correctly, and even tfsec didn't warn me about any errors. So we deployed the terraform with success.

resource "azurerm_resource_group" "downloads" {
  name     = local.resource_group_name_with_location
  location = var.location
}

resource "azurerm_storage_account" "downloads" {
  name                     = local.escaped_random_name_24
  resource_group_name      = azurerm_resource_group.downloads.name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  min_tls_version          = "TLS1_2"
}

resource "azurerm_cdn_profile" "resources" {
  name                = "${local.name}-cdn"
  location            = var.location
  resource_group_name = azurerm_resource_group.downloads.name
  sku                 = "Standard_Verizon"
}

resource "azurerm_cdn_endpoint" "resources" {
  name                   = "${local.name_with_suffix}-cdne"
  profile_name           = azurerm_cdn_profile.resources.name
  location               = var.location
  resource_group_name    = azurerm_resource_group.downloads.name
  is_http_allowed        = false
  is_compression_enabled = true

  content_types_to_compress = [
    "application/x-msdownload" # For .exe files
  ]

  origin {
    name      = "blob"
    host_name = azurerm_storage_account.downloads.primary_blob_host
  }
}

The problem

After it was provisioned we had to wait a couple of minutes, and sometimes a couple of hours while CDN got its configuration propagated. First, you will see HTTP 404 response and after a while, it should work. However, this was not the case. The error we were presented with was the following "InvalidUri" message.

<Error>
	<Code>InvalidUri</Code>
	<Message>The request URI is invalid. RequestId:bc46aeba-601e-0065-54b2-76b9e0000000 Time:2024-03-15T08:25:55.7419100Z
	</Message>
</Error>

Diagnosis

So, first things first, we checked if the blob storage was working and if we could download the files using the storage account URL ***.blob.core.windows.net/downloads/installer.exe and these were working just fine. So we can establish that the link between the CDN and the storage account is not correct. Thus I assumed a configuration error from my side.

Different Options

Another thing that didn't help to wrap my head around the problem is that there are multiple CDN options in Azure. Furthermore, everything has been consolidated in "Azure Front Door and CDN profiles", so whenever you create one manually. The options are:

• Microsoft CDN (classic)
• Microsoft Standard Edgio
• Microsoft Premium Edgio
• Microsoft Azure Front Door (more expansive and feature richt)

So I tried all of these options, as you can manually create them from your blob storage. And obviously, these were working out of the box. 😅

Having identified that 1; there is a configuration error, and 2; it is most likely caused by the way we create the Azure CDN profiles, we can narrow down our search. My previous searches (and assistance of ChatGPT) didn't get a hit, but having identified Terraform as a potential configuration problem, I was able to narrow down the search.

The solution

The problem is that the terraform template is missing the property origin_host_header. My next step would have been to manually compare the different endpoint configurations between the one created by Terraform and the one manually created, but I was able to find a Github issue with the same problem. It was one single property that I unfortunately overlooked. As you can see in the picture below, it is explained by inspecting this property in the Azure Portal that the Blob Storage and Web Apps require the origin host header to be specified. This is done for you when you manually create the CDN.
Thus, the correct terraform template should be like this for your CDN:

resource "azurerm_cdn_endpoint" "resources" {
  name                   = "${local.name_with_suffix}-cdne"
  profile_name           = azurerm_cdn_profile.resources.name
  location               = var.location
  resource_group_name    = azurerm_resource_group.downloads.name
  is_http_allowed        = false
  is_compression_enabled = true

  content_types_to_compress = [
    "application/x-msdownload" # For .exe files
  ]

  # ORIGIN_HOST_HEADER is required for connecting with Web Apps, Blob Storage and Cloud Services
  origin_host_header = azurerm_storage_account.downloads.primary_blob_host
  origin {
    name      = "blob"
    host_name = azurerm_storage_account.downloads.primary_blob_host
  }
}

Conclusion

It felt a bit counterintuitive to link two properties to the primary blob host, but it is necessary for it to work.  
I hope this post has helped you identify your problem working with Azure CDN and blob storage, provisioned by Terraform. However, I must give credit to Félix Prado as he was the one who was able to resolve this in his own Github issue.

Credit/Resources

Félix Prado

CDN endpoint is not working when configured using Terraform · Issue #3084 · hashicorp/terraform-provider-azurerm

Community Note Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request Please do not leave ”+1″ or “me too” comments, th…

GitHubhashicorp

Greetings once again, dear readers. It's been quite some time since my last entry, and I'm delighted to resume our discussion. In this ongoing series on ASP.NET Core testing strategies, today marks the unveiling of our third installment.

In our previous post, we ventured into the world of component tests, where we harnessed the power of TestDouble to replace HTTP calls and database interactions. If you happened to miss that piece, I highly recommend catching up, as it introduces a pivotal addition to your testing arsenal.

Now, let's turn our attention to the intriguing realm of integration tests. These tests serve as guardians, ensuring that your application interacts seamlessly with external components while upholding the integrity of your integration code. What sets this discussion apart is our incorporation of Docker, a tool that fortifies the robustness of the integration testing process.

But there's more in store for you. We'll also guide you through the seamless integration of these tests into your CI/CD pipeline, regardless of whether you prefer GitLab, GitHub Actions, or Azure Pipelines. So, stay with me as we embark on a comprehensive journey to integrate and test your ASP.NET Core applications with expertise and pragmatism.

Integrations with data stores and external components benefit from the fast feedback of integration tests. Tests in this style provide fast feedback when refactoring or extending the logic contained within integration modules. However they also have more than one reason to fail — if the logic in the integration module regresses or if the external component becomes unavailable or breaks its contract. - Toby Clemson

When to use integration tests

In the previous blog post, we have shown how we can use TestDoubles in order to test our components or microservices in isolation. We have seen that you can simply replace your database with an in-memory provider or replace your HTTP calls with a Mock in order to thoroughly acceptance test the behaviour. These component tests are low in build complexity and also execute relatively quickly. However, the thought of mocking entire external applications such as ElasticSearch with a TestDouble, is clearly too much work, and generally, these external applications come with the capability to run as a containerized version. So, in our XUnit unit tests, we are going to write some C# code, to startup some docker containers whenever we need one for an integration test. During some projects of mine, we used the following applications for integration tests:

• ElasticSearch (or OpenSearch if you use AWS)
• AWS DynamoDb
• Microsoft SQL Server or any other equivalen database provider such as Postgres, MongoDb, etc...

Our first integration test

So our requirements are simple. For each test we are running, there are a couple of steps we need to do.

1. Pull container: First we need to pull the docker image. This can either be done manually, in C# code or as part of a script in your CI/CD pipeline. In this blog I'll show you how to do it in code, but I would recommend the latter as this will help the execution speed of your builds and tests. Logically, once your test suite expands to 100's or 1.000's of tests, you don't want multiple tests competing to pull a container.
2. Create container: Secondly, once we have pulled the container, we need to create the container before we can start it with the required parameters.
3. Start container: Once created, we can start the container. Depending on the application you are running as a container, it might need some port binding configuration or environment variables.
4. Run integration test: Then, everything is prepared to run our XUnit test. We run our (now called integration tests), but we configure additional settings and services for our ASP.NET Core application using the TestHost helpers we have seen in our previous blogs.
5. Cleanup: Finally, we need to cleanup our used containers. (Or not, one scenario we used was to reproduce a bug that we were not able to understand. By keeping the container, we could inspect the logs of the external application, in order to find the problem).

To achieve all of this in code, Docker provides a NuGet package for a .NET client to interact with your Docker daemon programmatically. And it would look something like this.

But, this looks like a lot of work right? There is an easier way, but we'll get into that very soon. This code is just to demonstrate of all the steps that we need to do. In the next paragraphs we'll deep dive in making it more reusable by utilizing XUnit IClassFixture and we'll dive deeper into some more advanced scenarios

XUnit and Docker Containers

While the .NET client works great, it requires a lot of overhead in terms of code in order to write an integration test. Furthermore, in today's fast-paced software development landscape, efficiency and reproducibility are key. What we can do is to extract some of this code into a XUnit class fixtures. This offers a powerful combination that can improve your testing workflow. With Docker containers as XUnit class fixtures, you can effortlessly set up and tear down isolated environments for your tests, ensuring consistency across different test runs and environments. This approach not only simplifies the process of managing dependencies but also enhances the portability of your test suite, making it easier to share and collaborate with team members.

While developing this approach in our team, we found two significant challenges.

• Firstly, in a larger parallel test suite, when tests require the same dockerized application, you can get conflicts. This can either be when querying for the same database or containers trying to reserve the same port.  
• Secondly, some containers have extended startup times of 20-30 seconds before it can be invoked by C# code. You can have a rudimentary solution as Thread.sleep, but this won't work relabily. We need to implement a container readiness checks, either custom or with Docker Compose health checks, ensuring that the container its services are operational before running the integration test.

To make all these problems a bit more managable, we are going to use a different NuGet package, which is called TestContainers. And thus we can ensure smooth testing while harnessing the capabilities of Docker.

Testcontainers for .NET

Menu

Our revised integration test

Considering the above, your code could look somthing like this. We have made an abstract class called ContainerFixture, with the responsability to make sure our container automatically is started, stopped, and cleaned up. Then, we can make multiple implementations which focus on just specifying the container. As you can see, we make a PostgresContainerFixture which starts a postgress database for our orders API. This API is the one we have been using the last two posts.

The second thing we need to do, is to update our integration test to configure either an URL or a connection string to the started container. This is quite similiar how we have already done this in our component test in our previous blog when we were using the Entity Framework in-memory solution.

And thus we can run our tests and inspect what is happening in the background during an integration test. Below in the screenshot you can see 3 containers being run. One is the TestContainer "side car", which manages the containers during your tests. The two other containers are the postgres databases which are used by our integration tests that run in parallel. Here we can see and confirm that the Postgres port 5342 is randomly assigned on the host to prevent conflicts.

Waiting for ElasticSearch to be ready

Wonderful! Our test are running but there is more problems we need to address. As mentioned before, some containers take a while to startup (I'm looking at you ElasticSearch 👀). Now in our case, we were doing even more complicated stuff. We had two applications which integrated with ElasticSearch. To make a long story short, we had one application writing the data, and another one responsible for reading and search. While settings this up, we of course ran into the forementioned problems of conflicts. But, we were able to write a big chunk of reusable code in order to load the data and prepare the integration test.  

However, the main problem was waiting for the container to fully start. Since it was taking atleast 20-30 seconds, we didn't want to start a new container for every TestClass. This would add a lot of overhead, in terms of compute resources but also execution time. One thing we did was to ping the ElasticSearch healthcheck endpoint every 5 seconds, until we got back a green status. While rudamentry, it was working for us. Fortunately, TestContainers provides a number of prebuild containers and they have a much easier way to validate if the ES is ready to receive requests. Look at this list of prebuild container builders from TestContainers.  

_{Azure Cosmos DB, Azure SQL Edge, Azurite, ClickHouse, Couchbase, CouchDb, DynamoDB, ElasticSearch, EventStoreDb, InfluxDB, K3s, Kafka, Keycloak, LocalStack, MariaDB, MinIO, MongoDB, MySQL, Neo4j, Oracle, PostgreSQL, RabbitMQ, RavenDB, Redis, Redpanda, SQL Server, WebDriver}

So plenty to choose from! If you want a bit more control over your container, I would recommend writting some code of your own.

Continuous Integration

Last but not least, we want to run all of this in our continuous integration/deployment tools in order to verify the behaviour of our application before we deploy them. To use TestContainers in your CI/CD environment, you only require Docker installed in your prefered agent. A local installation of Docker is not mandatory; you can also use a remote Docker installation. Below you'll find a couple of examples for three (or two if you look at it) different tools. TestContainers also prints some logs on what is happening.

GitHub

Microsoft-hosted agents come with Docker pre-installed, there is no need for any additional configuration. It is important to note that Windows agents use the Docker Windows engine and cannot run Linux containers. If you are using Windows agents, ensure that the image you are using matches the agent's architecture and operating system version.

Azure Pipelines

Both GitHub and Azure Pipelines use the same hosted build agents so the same remarks apply.

GitLab

And finally, to configure the Docker service in GitLab CI (Docker-in-Docker), you need to define the service in your .gitlab-ci.yml file and expose the Docker host address docker:2375 by setting the DOCKER_HOST environment variable. Below the output and the code.

Conclusion

In conclusion, our exploration of integration testing in ASP.NET Core has been enlightening. We've seen how Docker can enhance these tests by simplifying dependency management and improving portability.

We've also tackled common integration testing challenges, such as conflicts in parallel test suites and dealing with slow-starting containers, using the TestContainers NuGet package.

Additionally, we've discussed how to integrate these tests into your CI/CD pipeline, ensuring your applications are thoroughly tested before deployment, whether you're using GitHub, Azure Pipelines, or other tools.

In the world of software development, mastering integration testing with Docker and TestContainers is essential for efficient and reliable application development. Armed with these insights, may your tests run smoothly, and your applications thrive. Happy coding!

Resources/Credits

DigitalOcean | Cloud Hosting for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

Cloud Hosting for Builders

Testing Strategies in a Microservice Architecture

The microservice architectural style presents challenges for organizing effective testing, this deck outlines the kinds of tests you need and how to mix them.

martinfowler.comToby Clemson

GitHub - rikvandenberg/aspnetcore-component-tests at part-3

Contribute to rikvandenberg/aspnetcore-component-tests development by creating an account on GitHub.

GitHubrikvandenberg

In the previous post, we looked at some of the basics steps for writing tests for our REST API in ASP.NET Core. We learned how to self-host our API, send HTTP requests to execute our test, customize logging to report details of these tests, and customize our settings. More specifically, we showed how to replace our external dependencies, such as a database, through dependency injection with an in-memory version that used a list. That post was a small preview of what is to come and what we will be addressing in this post. With the techniques from the previous post in place, we can run our application as deployed in a test without any external calls. By replacing these external calls with TestDoubles, we start to create a boundary and isolate our API. These kinds of tests are more known as component tests. In this post, the second part of a three-part series, we will go into more depth about component tests. We will talk about:

• Introduction about component tests
• Overview of NuGet packages we are using
• Replacing integrations with TestDoubles

We will go into depth about the kind of integrations we will be replacing with a TestDouble. All of this, we will do with the help of dependency injection. Some examples are:

• EntityFramework: Replace DbContext by using the in-memory versions
• HTTP integration: Replace HttpClient with a special handler that simulates our requests.

And finally, we will put all these examples together into a single component test. Let us get to it because there is a lot to discuss.

Introduction

To understand what we are going to do in this post, it is best to look at the definition of a component test. I very much like the description and the presentation from Martin Fowler and Toby Clemson - Testing Strategies in a Microservice Architecture. This post outlines everything about this topic. It serves as a precise definition, one that we will apply in our examples, and serves as a thread through our posts. I highly recommend reading it.

A component test is a test that limits the scope of the exercised software to a portion of the system under test...where component tests deliberately neglect parts of the system outside the scope of the test. - Toby Clemson

Looking at the definition and the above image, we can quickly see the boundary of the component test. The goal of the component test is to limit the scope to only your code. It places any external parts, such as a database or an HTTP service, outside the system. But there could be many more moving pieces in your application. Some other examples we've identified in our application are things like caches, files, streams, message publisher/subscribers, and many more. In practice, when writing these tests yourself, you'll have to identify these "parts of the system" that are outside of the scope of your test.

Once identified, we can look at the second part of the definition. This part is about "neglecting" these external dependencies. With the help of dependency injection (as you might have seen in the previous post), we will replace part of our code with a TestDouble. But the question is, which classes do we have to replace? Let's take a look at the class structures.

As an example, take the above class diagram. Here we need to find the lowest level of integration to replace with dependency injection. You can see that the implementation of the ShopifyProductsClient has a dependency on the HttpClient. It uses this class to add additional headers such as an API key and makes sure the response is valid. Furthermore, this client is exposed through the abstraction of an interface called IProductsService. The implementation of this service is not at the lowest level. Suppose you replace the interface with a dummy implementation returning a single product. When doing so in your component test, you are only replacing part of your code and you are not really testing the implementation of the service. It would be better if you have a way to control the  HttpClient and its respective requests and responses. This kind of control will allow you to simulate how an external API call such as Shopify responds. You can assert that your microservice adds the API key to the headers and handles the happy flow well. This method also allows you to test how your service responds resiliently to an HTTP 4XX or 5XX response.

Some NuGet packages are we using...

Moq
Moq is a package that, in their own words, "is intended to be simple to use, strongly typed (no magic strings!, and therefore full compiler-verified and refactoring-friendly) and minimalistic (while still fully functional!)". I've worked with Moq for a very long time and it suits most of my needs when I need to inject an abstraction into my SystemUnderTest. Moq can serve both as a Mock and a Spy at the same time. On one side it requires you to set up your expectations for the class/interface that is being called and respond in a certain way. On the other side, it also allows you to verify invocations such as how many times it was called, with what parameters, etc, etc.

var mock = new Mock<IFoo>();

// basic example
mock.Setup(foo => foo.DoSomething("ping")).Returns(true);

// access invocation arguments when returning a value
mock.Setup(x => x.DoSomethingStringy(It.IsAny<string>()))
		.Returns((string s) => s.ToLower());

// throwing exceptions when invoked with specific parameters
mock.Setup(foo => foo.DoSomething("reset")).Throws<InvalidOperationException>();
mock.Setup(foo => foo.DoSomething("")).Throws(new ArgumentException("command"));

AutoFixture
AutoFixture is a library that aims to simplify the setup for your tests. Generally speaking, when writing a unit test, you need to write some code to arrange some data. Complex objects like Customer, Order or maybe an even more complex structure. When you need large datasets or POCO's with a high number amount of properties, it is very tedious to set these tests up. I often write a factory class that has some logic to construct data for my domain. But when I'm not interested in what the data is, I used AutoFixture.

[Fact]
public void IntroductoryTest()
{
    // Arrange
    Fixture fixture = new Fixture();
    Customer sut = fixture.Create<Customer>();
    
    // Act
    int result = sut.GetNumberOfOrders();
    
    // Assert
    Assert.Equal(expectedNumber, result);
}

MockHttp
MockHttp is a testing library for Microsoft's HttpClient class. It allows stubbed responses to be configured for pre-defined HTTP requests and can be used to test your application's service layer. Looking at the aforementioned architecture image, this will help us to replace/intercept "Live HTTP" clients with "Stubbed HTTP" clients. It's great when there are one or multiple HttpClient integrations in your application.

Most of the aforementioned packages will be used in the next examples.

Replacing integrations with TestDoubles

By instantiating the full microservice in-memory using in-memory test doubles and datastores it is possible to write component tests that do not touch the network whatsoever. This can lead to faster test execution times and minimizes the number of moving parts reducing build complexity. However, it also means that the artifact being tested has to be altered for testing purposes to allow it to start up in a 'test' mode. Dependency injection frameworks can help to achieve this by wiring the application differently based on configuration provided at start-up time.

Not much more than the above quote needs to be said about our component tests. The tests run incredibly fast and give us a good idea of how the application will behave. I've been building mostly backend APIs, and having the possibility to assert the outcome of an individual API regressively is a big plus for our development team. In the following paragraphs, we will put everything together. Per "integration", I'll go over an example on how to replace the implementation to support a component test. Additionally, you will find the source code on the bottom of the post in the resources section.
We have examples for:

• Entity Framework
• HttpClient

While these are are only few and limited examples, these should be enough for your first main cases. But for other integrations, we generally found that they offer docker containers. This will be a subject for a later post.

Replacing the (relational) database

Before going into too much detail, it is important to understand that there are a number of trade-offs when component testing your database/repository code. Below you will find a number of examples resembling the pros and cons from the documentation mentioned here: Testing code that uses EF Core. Essentially, depending on your type of TestDouble, there is a different level of integration with SQL/Entity Framework.

• InMemoryRepository: no integration with entity framework or SQL. Just a
  self-made class with a list or dictionary
• Entity Framework in-memory: No support for transactions or raw SQL
• SQLite: Closest to database interaction, but not production worthy

Depending on your scenario or component test, you can exchange these options and choose to adopt one or multiple solutions. In the example source code, you will find all three examples.

InMemoryRepository (No integration)
Assuming you have some sort of IRepository interface, we can use dependency injection to replace from our previous post to provide an implementation with a version that uses a List<T>  or a Dictionary<TKey,TValue>. There are a couple of advantages to this scenario. First, you don't have to worry about setting up the data. If you have a complex database, you might need to insert dependent data before you have it in the desired state for your test. Secondly, the "ConfigureTestServices" is relatively simple.

.ConfigureTestServices(services =>
{
    services.AddSingleton(typeof(IRepository<>), typeof(InMemoryRepository<>));
});

However, the big disadvantage is the component test never covers your Object-relational mapping (ORM) framework. Ideally, it is much better to run against an actual database to test the integration as it is closer to the deployed scenario and can identify early integration mistakes. The challenge, in this case, is that it must also be able to run during your CI/CD pipelines. Furthermore, you need to make sure that if you run your component tests in parallel, that they don't conflict with one or another. Using an in-memory database may or may not be available to you depending on the ORM framework you use.

Using entity framework in-memory (Low integration)
In our case, EntityFramework does support this with Microsoft.EntityFrameworkCore.InMemory NuGet package. The setup is simple but switching database providers requires some additional Dependency Injection tricks. When invoking the services.AddDbContext<MyDbContext>(), some additional steps are done by EF. It registers two services.

• A service to resolve DbContext
• A service/factory method to resolve DbContextOptions<MyDbContext>.

The preferred database provider is registered in these options. Thus, in order to switch the database provider from your default to the in-memory version, we need to override these options. Be aware that any other configuration you might have done, like enabling detailed errors, are also is overridden and needs to be reconfigured. Below is an example that uses the EntityFramework in-memory database.

webHostBuilder
    .ConfigureTestServices(services =>
    {
        // Depending on the LifetimeScope of your options, it might either must be Scoped or Singleton. Default it's Scoped
        services.AddSingleton((serviceProvider) =>
        {
            var optionsBuilder = new DbContextOptionsBuilder<OrderDbContext>().UseInMemoryDatabase("orders");
            return optionsBuilder.Options;
        });
    });

Using SQLite in-memory (Medium integration)
For the SQLite option, we need to do a similar thing with our dependency injection. As you can see in the above example, configuring a different database provider is very easy, but for SQLite, we need to implement the IDisposable interface because we are working with external resources such as a database connection. To achieve this, you typically use a Setup/Teardown pattern. xUnit uses the UnitTest class constructor as "Setup", and the IDisposable.Dispose will be the "Teardown".

public class SqlLiteComponentTest : IDisposable
{
    private readonly DbConnection _connection;

    public SqlLiteComponentTest(ITestOutputHelper testOutputHelper)
    {
        // Ommitted
        _connection = CreateInMemoryDatabase();
    }

    private void CustomizeWebHostBuilder(IWebHostBuilder webHostBuilder)
    {
        webHostBuilder
            .ConfigureTestServices(services =>
            {
                services.AddSingleton((serviceProvider) =>
                {
                    var optionsBuilder = new DbContextOptionsBuilder<OrderDbContext>()
                        .UseSqlite(_connection);
                    return optionsBuilder.Options;
                });
            });
    }

    private static DbConnection CreateInMemoryDatabase()
    {
        var connection = new SqliteConnection("Filename=:memory:");
        connection.Open();
        return connection;
    }

    // Ommitted

    public void Dispose()
    {
        _connection.Dispose();
    }
}

Again, it is important to note that depending on your scenario, you might choose one of the above options for your own component tests. Each choice has a different trade-off, as they work differently and provide a different level of integration to the database. But as shown here, getting started with these options are equally as simple, and they all work interchangeably.

Replacing HttpClients with a MockHttpHandler

Another low level of dependency is your HttpClient. In our example application from the previous blog, we have created a service that integrates with Shopify. Now we can write a test that calls our order API, but that would fail because it tries to connect with the Shopify service. We need a way to work to intercept this, and we will be doing this with the MockHttp library.

Before writing a test, I generally use Postman to get an example requests and responses, and I store these inside a JSON file. With the help of these files, you can quickly set up a request in your code (specifying HttpMethod, QueryString and Headers) and returning a response the same way the API does. Below you'll see an example of such a setup.

MockHttpMessageHandler
    .When(HttpMethod.Get, "https://shopify/api/v1/products/admin/api/2021-07/products/APPLE_IPHONE.json")
    .WithHeaders(new Dictionary<string, string>
    {
        ["X-Shopify-Access-Token"] = "secret"
    })
    .Respond(MediaTypeNames.Application.Json, File.ReadAllText("Shopify/Examples/APPLE_IPHONE.json"));

This is a convenient way of making component tests for your HTTP integrations.  
Furthermore, in my personal experience, it has helped our team to even reproduce bugs. There were certain cases that we did not foresee, and through diagnosing and mimicking the request/response in a component test, we were able to quickly identify and resolve the bug, complementing our code base with another component test.

The component test

Bringing all this together we can create the following component test. This test first asserts that there are no orders, then it creates an order, and last but not least, it verifies that the order was created. This component test thus asserts that the HTTP integration works with Shopify. Additionally, it asserts our database is storing the order and we can retrieve it with all the correct details.

[Fact]
public async Task ComponentTest()
{
    // Arrange
    MockHttpMessageHandler
        .When(HttpMethod.Get, "https://shopify/api/v1/products/admin/api/2021-07/products/APPLE_IPHONE.json")
        .WithHeaders(new Dictionary<string, string>
        {
            ["X-Shopify-Access-Token"] = "secret"
        })
        .Respond(MediaTypeNames.Application.Json, File.ReadAllText("Shopify/Examples/APPLE_IPHONE.json"));

    // Act #1
    HttpResponseMessage getAllResponse = await SystemUnderTest.GetAsync("/api/v1/orders");
    var orders = await getAllResponse.Content.ReadFromJsonAsync<Order[]>();
    orders.Length.Should().Be(0);

    // Act #2
    HttpResponseMessage createResponse = await SystemUnderTest.PostAsync(
        "/api/v1/orders", 
        JsonContent.Create(new CreateOrderDto()
        {
            ProductNumbers = new[] { "APPLE_IPHONE" },
            UserId = Guid.NewGuid(),
            TotalAmount = 495m,
        }));

    // Act #3
    getAllResponse = await SystemUnderTest.GetAsync("/api/v1/orders");


    // Assert
    createResponse.StatusCode.Should().Be(HttpStatusCode.OK);
    getAllResponse.StatusCode.Should().Be(HttpStatusCode.OK);
    orders = await getAllResponse.Content.ReadFromJsonAsync<Order[]>();
    orders.Length.Should().Be(1);
}

Conclusion

And that is we can create component tests. To summarize, we have done a couple of things.

• We have talked about component tests and what they are
• We showed some NuGet packages that can help you with these component tests
• Replaced an HTTP integration with examples
• Replaced EntityFramework to run different in-memory modes
• Brought all the above together into a single component test

Writing component tests takes longer but the advantage is that you can create fine-grained tests that match some use cases or scenarios. This helped me and my co-workers to develop more reliable applications. In particular,  for us, it became easier to reproduce bugs.

The scope of this post was to show you, how to create component tests. While they are great as a starting point to get a high "code coverage" and confidence in your application, there are still many more libraries that you can use to solve your functional or technical requirements.  For example, look at Redis, RabbitMq, ElasticSearch, MongoDB, etc. However, these libraries are harder to replace with a TestDouble. Instead, many of these libraries, when working in cloud-agnostic environments, provide a docker container implementation. In the next blog, I'm going to show you how to spin up Docker Containers during your xUnit test so that we can use containers to provide an actual integration. These new kinds of tests then become integration tests. I would love to hear what your thoughts are.

By combining unit, integration and component testing, we are able to achieve high coverage of the modules that make up a microservice and can be sure that the microservice correctly implements the required business logic. - Toby Clemson

Next post

Different kind of testing strategies with ASP.NET Core: Using Docker to write Integration tests

Greetings once again, dear readers. It’s been quite some time since my last entry, and I’m delighted to resume our discussion. In this ongoing series on ASP.NET Core testing strategies, today marks the unveiling of our third installment. In our previous post, we ventured into the world of component

.NET from the mountainRik van den Berg

Resources / Credits

DigitalOcean | Cloud Hosting for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

Cloud Hosting for Builders

Testing Strategies in a Microservice Architecture

The microservice architectural style presents challenges for organizing effective testing, this deck outlines the kinds of tests you need and how to mix them.

martinfowler.comToby Clemson

GitHub - rikvandenberg/aspnetcore-component-tests at part-2

Contribute to rikvandenberg/aspnetcore-component-tests development by creating an account on GitHub.

GitHubrikvandenberg

Most enterprises or development teams will have a quality gate in place, which dictates a percentage of code coverage. When writing new or changing your existing code, you also need to supplement them with unit tests. I enjoy writing unit tests when they have a more functional purpose. For example, creating orders containing products with discounts, testing a regression, or confirming the cause of a bug. Looking back at some of the tests I've been writing myself with ASP.NET Core, there is more than meets the eye. These tests fit more in a different category of the testing pyramid. From top to bottom, we have:

• End-to-End tests
• UI tests
• Integration tests
• Unit tests

The higher we go in the pyramid, the more effort it takes to write these tests. During a "rebuild" project, we had a dedicated tester available. This rebuild project was to migrate some REST API's from ASP.NET 4.5 into ASP.NET Core. With containerization being a trend, we also decided to deploy and develop these API's using Docker. As we were optimizing our workflow, we also needed some initial end-to-end testing to be done. However, the work done by our tester was mostly manual (both for the legacy and the new applications).

While we were producing both ends of the spectrum as a team, we were still looking to increase our throughput for deliverables. When we started automating part of our test suite, we stumbled into the component/integration test area. But, our tester, who could write code, wasn't very well-known in the .NET core/Docker space. So we helped him with writing some code to self-host the app to send HTTP requests to the API.

Our example application
For these blog posts, I will use an example application to explain the ideas behind component testing. I build a small REST API application with dependencies to a SQL Database and an integration with an HTTP API. At the bottom of this blog, you will find the code in the resources.

What's next?
In the next couple of blog posts, I will describe how we can get started with ASP.NET Core and xUnit to create a component or an integration test. As a foundation for the other posts, this first blog post teaches you:

• The basics of self-hosting the ASP.NET Core application in xUnit
• Using WebApplictionFactory and how to customize the startup
• Change/configure settings for your test
• How to replace dependencies such as an SQL database, RabbitMQ or HTTP clients
• View everything logged by your application during a test

With this introduction out of the way, let us get started.

| Note: While each test in the pyramid has a different goal, xUnit doesn't classify or mark these tests differently. A test in xUnit is a method which means that a method can be a unit test, a component test, or an integration test.

Sending HTTP requests to your ASP.NET Core application in a unit test.

In our example application, we have a REST API. It is written with ASP.NET Core, and to start sending HTTP requests to this application, we need a way to host it. To achieve this, we need to carry out a couple of steps. ASP.NET Core was built with extension in mind and comes out of the box with self-hosting capabilities. In the Microsoft.AspNetCore.Mvc.Testing NuGet package, you will find a WebApplicationFactory<TEntryPoint> class (where TEntryPoint is either your Startup or Program). This class is capable of self-hosting the application anywhere in your code. Once this factory has started our API, we can then use this factory to resolve a HttpClient.

We can choose to create or inject our factory and resolve the HttpClient. This factory will do a couple of things for us. It establishes a TestServer that runs our self-hosted application. This server is responsible for hosting the application. It is similar to IIS, Kestrel or whatever your flavour might be. It configures the entire request pipeline and then starts processing requests. With the HttpClient, we then send out an HTTP request to an endpoint; in our case, this is GET /api/v1/orders, and we assert that the response is 200 OK.

public class OrderApiComponentTest
{
    private readonly WebApplicationFactory<Program> _webApplicationFactory;

    public OrderApiComponentTest()
    {
        _webApplicationFactory = new WebApplicationFactory<Program>();
    }

    [Fact]
    public async Task When_GET_is_called_on_the_api_should_return_200_OK()
    {
        // Arrange

        // Act
        HttpResponseMessage response = await SystemUnderTest.GetAsync("/api/v1/orders");

        // Assert
        response.StatusCode.Should().Be(HttpStatusCode.OK);
    }

    public HttpClient SystemUnderTest =>
        _webApplicationFactory.CreateClient();
}

With this as our foundation, we can start looking into more details. Depending on your application, this test might fail due to dependencies such as databases or other services not connecting. But we will try to resolve this along the way.

WebApplicationFactory<TEntryPoint> deep dive

Startup or Program
The WebApplicationFactory<TEntryPoint> is used to create a TestServer. The TEntryPoint is a class that can either be the Startup or the Program. It doesn't really matter which one you use. The factory will use to entry point class use the assembly of the class to then try to discover one of the following static methods:

• IWebHost CreateWebHost(string[] args)
• IWebHostBuilder CreateWebHostBuilder(string[] args)
• IHostBuilder CreateHostBuilder(string[] args)

When discovered, this method is then invoked and used to start and run the app. If it doesn't find this public static method, it will fail to startup.

Some NuGet packages or libraries that are available will tell you to customize this builder/host method. For them to hook into the ASP.NET Core runtime. For example, AutoFac is a library that changes the ServiceProvider. And we have written some libraries for our own projects that used custom initialization code in our Program Main() method to perform additional initialization tasks.  

However, the factory doesn't invoke this Main() method. In the below (incorrect) example, the Main() method declares that AutoFac should be used as ServiceProvider. But because the factory only invokes the static method, AutoFac will not be configured for our test. So if you decide to add additional startup code to your main method, make sure it is invoked separately in your test. Or, you can create a custom class that inherits WebApplicationFactory<T> that does this for you.

public class Program
{
    // Any custom code here is not invoked by WebApplicationFactory.
    public static async Task Main(string[] args)
    {
        IHostBuilder hostBuilder = CreateHostBuilder(args);
        hostBuilder.UseServiceProviderFactory(new AutofacServiceProviderFactory())
        IHost host = hostBuilder.Build();
        await host.RunAsync();
    }

    // Discovered and invoked by the WebApplicationFactory
    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)            
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

Resolving services to arrange your data
The WebApplicationFactory not only gives us the ability to host the application, but it also exposes the IServiceProvider of our application. This means we can resolve all of our services that have been registered inside our application. For example, if we need to pre-populate our database with some customers, we can resolve a repository to add some data.

If your classes are registered as singleton or transient, you can use the Services property on the factory. But if your classes are registered as scoped, you also need to resolve these services as scoped. We will populate our customers in the arrange step of our test.

// Arrange
IRepository<Customer> customers = 
    _webApplicationFactory.Services.GetRequiredService<IRepository<Customer>>();
customers.CreateAsync(new Customer(...));

// Arrange in scoped
using (IServiceScope scope = _webApplicationFactory.Services.CreateScope())
{
    IRepository<Customer> customers = scope.ServiceProvider.GetRequiredService<IRepository<Customer>>();
    customers.CreateAsync(new Customer(...));
}

Adding custom appsetting.json

Even Though we are self-hosting our application in a xUnit test, the application works the same as when you host in on IIS, cloud or Docker environment. One of the things ASP.NET Core automatically does is load a bunch of settings from different sources. But for your tests, you might need a way to override these. The runtime loads them in the following order: app settings, environment-specific settings, user secrets, system environment, and last but not least, the console arguments.

To override these settings, we can customize the factory to customize our web host. Our goal is to load additional app configurations specific to only our test. In the factory class, we have to call the WithWebHostBuilder method, which is a callback with the IWebHostBuilder as parameter.

public class OrderApiComponentTest
{
    private readonly WebApplicationFactory<Program> _webApplicationFactory;
    private readonly ITestOutputHelper _testOutputHelper;

    public OrderApiComponentTest(ITestOutputHelper testOutputHelper)
    {
        _webApplicationFactory = new WebApplicationFactory<Program>().WithWebHostBuilder(CustomizeWebHostBuilder);
        _testOutputHelper = testOutputHelper;
    }

    private void CustomizeWebHostBuilder(IWebHostBuilder webHostBuilder)
    {
        webHostBuilder
            .ConfigureAppConfiguration((context, configuration) =>
            {
                string folder = Path.GetDirectoryName(GetType().Assembly.Location);
				string file = "ComponentTest/component.test.json";
				configuration.AddJsonFile(Path.Combine(folder, file));
            });
    }
}

To load the test-specific settings, you need to make sure you fully specify the path to your settings file. The application has a content root and a webroot. The content root is the one that is used to load assemblies, JSON/XML/DB files, and Razor views. But this content root is located in the project that you are self-hosting. In our case, that is the "Api" project. So when you only specify, for example, "ComponentTest/component.test.json", it will not find the file because it is located in our "Api.Test" project.

So with the customizations in place for the web host, we can edit our JSON file to include settings. Additionally, we can write a test to assert the correct settings are loaded instead of our original values from the user secrets.

{
  "Shopify": {
    "ApiKey": "COMPONENT_TEST"
  }
}

[Fact]
public async Task When_application_starts_up_should_load_config_from_json_file()
{
    // Arrange
    IConfiguration configuration = _webApplicationFactory.Services.GetRequiredService<IConfiguration>();

    // Act/Assert
    configuration["Shopify:ApiKey"].Should().Be("COMPONENT_TEST");
}

Changing dependencies by using Test specific Dependencies

If you use a relational database, a message queue or a NoSql database, we need to start thinking about how these dependencies will work if we self-host the application. During the development of your app or executing these tests locally on your own machine, they might have a chance of succeeding. But this might not be the case for everything. And if you have a continuous integration (CI) pipeline, running these tests on that build agent could also fail. The goal of these component/integration tests is that we are trying to make them so that they can also run inside a CI/CD environment.

So we need to replace some of our dependencies. Generally speaking, a Startup class will have a method called ConfigureServices(IServiceCollection services) where all our dependencies are registered. But during our tests, we might need to replace some services to pass the tests. For example a IRepository, IBasicConsumer or any other dependency with an abstraction. For now, we will be replacing these services with a TestDouble.

To achieve this, we will call a special method ConfigureTestServices on the host builder. This is a special callback that is executed after your Startup.ConfigureServices and is only available when used in combination with the WebApplicationFactory<T>. This method allows you to override any previously registered services and replace them with something else, like a fake. Alternatively, this callback is also a place to configure test specific behaviour further. For example, configuring EntityFramework to use the SQLite implementation instead of a SQL server or, change how HTTP client/services are resolved.

private void CustomizeWebHostBuilder(IWebHostBuilder webHostBuilder)
{
    webHostBuilder
        .ConfigureTestServices(services =>
        {
            services.AddScoped<IRepository<Customer>, InMemoryRepository<Customer>>()
            services.AddSingleton<IBasicConsumer>(new FakeBasicConsumer())
                    
            // Etc
        });
}

Adding output using logging with xUnit

Last but not least, we are going to take a look at logging. Again ASP.NET Core automatically sets this part up for us. But in your company, you might be using an Application Performance Management (APM) tool such as DataDog or Application Insights. If you have configured these third party APM systems, your component or integration test will be sending logs to these tools. So we want to prevent that, but when debugging or investigating issues, it is still useful to have some form of logging. xUnit comes out of the box with a ITestOutputHelper class. Anything that is written to that class during your test is stored as an output with the test.

Together with the NuGet package, Xunit.Extensions.Logging we can register this class as an implementation of ILogger. First, we have to remove all of the other log providers to send anything to your APM. And then, we will add the xUnit ITestOutputHelper class. Any logs will then be written as output and be available in the test explorer, as shown in the above picture. This must also be done to customize our web host builder by using the ConfigureLogging() method. First, we accept ITestOutputHelper as a constructor parameter of the test class. And then, we register the xUnit class with our logging builder.

// Accept ITestOutputHelper as constructor parameter.
public OrderApiComponentTest(ITestOutputHelper testOutputHelper)
{
    _webApplicationFactory = new WebApplicationFactory<Program>().WithWebHostBuilder(CustomizeWebHostBuilder);
    _testOutputHelper = testOutputHelper;
}

private void CustomizeWebHostBuilder(IWebHostBuilder webHostBuilder)
{
    webHostBuilder
        .ConfigureLogging(loggingBuilder =>
        {
            loggingBuilder.ClearProviders();
            loggingBuilder.AddXunit(_testOutputHelper);
        });
}

Conclusion

With this post as our foundation, we will continue to explore writing component and integration tests for ASP.NET Core. You might have already seen some hints of what a "component test" can look like. This post has shown you some of the basics that we will be using when testing an ASP.NET Core application in a xUnit test. We have gone through:

• Self-hosting our web application in a test using xUnit
• Customizing the application with WebApplicationFactory
• Adding test specific settings
• Replacing dependencies specific to the test
• Replacing existing logging with the xUnit output for additional debugging purposes

We will go deeper into how we can write our component and integration tests in the next posts.

Next post

Different kinds of testing strategies with ASP.NET Core: Component tests

Writing component tests takes longer but the advantage is that you can create fine-grained tests that match some use cases or scenarios

.NET from the mountainRik van den Berg

Resources

DigitalOcean | Cloud Hosting for Builders

Simple, scalable cloud computing solutions built for startups and small-to-midsize businesses.

Cloud Hosting for Builders

Testing Strategies in a Microservice Architecture

The microservice architectural style presents challenges for organizing effective testing, this deck outlines the kinds of tests you need and how to mix them.

martinfowler.comToby Clemson

Integration tests in ASP.NET Core

Learn how integration tests ensure that an app’s components function correctly at the infrastructure level, including the database, file system, and network.

Microsoft DocsRick-Anderson

GitHub - rikvandenberg/aspnetcore-component-tests at part-1

Contribute to rikvandenberg/aspnetcore-component-tests development by creating an account on GitHub.

GitHubrikvandenberg

It feels great to have a professional (and personal) blog space. I enjoy writing about technical stuff and my experiences. And over the past years, I've attempted many times to launch a blog, but most of these attempts failed. The idea of hosting, deploying and managing everything was very looming and off-putting. I often find myself falling into a rabbit hole trying to solve these things through automation. Creating a fully automated CI/CD pipeline to satisfy all of my wishes. But then, in the end, I always gave up because the direction or result just wasn't there.

| Note: No later than a couple of weeks, Ghost has release version Ghost 4.0 and offers a subscription starting at $9 (yearly). However, if you are a little more technical and want access to more features and customizations, I would recommend continuing to read the post below.

I finally found a setup easy enough to start with, and I'm delighted. Looking back, I could have made things easier for myself. I'm probably not going to use all of the things that are now at my disposal. But funny enough, it's always nice to have additional tools😉 Let us go through the list of technical things I've chosen, starting with Ghost.

The spooky blog

So as my blog, I choose Ghost. It is not really a blog but more of a publishing platform. Over the past couple of months, I've always been drawn back to the list of features offered by them. For publishing, it offers an overall complete experience. It uses Markdown, which makes writing posts with code very friendly. Tagging featured posts and SEO makes my content more (hopefully) findable and organized. Anything that is a basic necessity for a blog.

You can style your website by choosing a theme available through different marketplaces. Both free or paid themes are available, or you can even make your own. It was one of the experiments, and it was fun and great to learn more about Ghost. It also led me to explore JAMStack and Gatsby.JS. But enough about that rabbit hole.

Last but not least, Ghost has a more noteworthy feature which is its members and subscriptions. Your readers can register for free, and allows them to receive notifications/newsletters when you publish them. But they can also subscribe for a monthly or yearly fee. Respectively allowing you to publish content accessible to registered users only or paying users. Some more thoughts of why I ended with Ghost:

• Audience: interaction with the readers through many means such as sharing, comments and newsletters.
• Newsletters: You will have to connect a mailing service such as MailGun to start sending emails, but I really like the idea of having the option to start sending newsletters about maybe the smaller things that I run into and are not worth a post. Additionally, Ghost allows you to segment your emails, giving you the option to send them to free members or paid members (or both).
• Business: As this is a professional blog, any future business opportunities or career paths that open up are great bonuses.
• Integrations: Comments, analytics, workflows. The possibilities are great, although I don't see myself using anything special. Here is a list of all the integrations currently possible.

Ghost: Turn your audience into a business

The world’s most popular modern publishing platform for creating a new media platform. Used by Apple, SkyNews, Buffer, OpenAI, and thousands more.

Ghost - The Professional Publishing Platform

Choosing the right vessel for the sea of internet

While exploring Ghost as a blog, I also looked into the hosting options. Ghost is a non-profit organization, and to support that organization, they offer a hosting service called Ghost(Pro). This service costs $36 or $29 per month, depending on your prepay for the year. This price is unattractive for just trying to start a blog.

But Ghost also documents some alternatives. Whether it is self-hosted or containerized with Docker. Working with containers has taught me to appreciate enough simplicity of creating a container and deploying it in different clouds, such as AWS or Azure. But these experiments again left me with a sour aftertaste. The overhead of creating a container, managing the database and testing each consecutive change put me off and stopped me in my tracks to further progress. So what I really wanted was a single click deployment without worrying too much about backup, configuration, and such.

Luckily Ghost has an official partner DigitalOcean, and they provide prebuilt packages. Even better, they provide a "Ghost 1-Click App" on their marketplace and promise to have an instance up and running in 2 minutes. They offer a couple of sizes for virtual machine sizes, and the cheapest one with decent performance comes for $5 per month. This is a great starting price, and for the first 2 months, there is a free $100 credit.

How to install Ghost on Digital Ocean - Official guide

A full production install guide for how to install the Ghost professional publishing platform on a production server running Ubuntu 16.04, 18.04 or 20.04.

Ghost - The Professional Publishing Platform

All that is required from you is that you bring your own domain. If you don't have one at the moment, that is fine. You can come back after creating the VM. The installation guide was easy enough, and after following every step, I had my blog running, as promised, in a couple of minutes. Since I didn't have a domain yet, I was playing around a bit with ghost using the IP address of the VM.

After purchasing my domain, I followed this handy guide on how to connect my domain to the Virtual Machine. After that, I impatiently waited for things to propagate, and presto, everything was working as expected. With the domain connected, it was time to go back to the VM and set up the SSL.

1. Connect to the VM using an SSH session
2. Login as ghost-mgr  sudo -i -u ghost-mgr
3. Navigate to the ghost folder location. Typically at /var/www/ghost/
4. Run ghost setup ssl and follow the instructions

And that was it—time for the launch. Let the countdown begin. 10...9...8...

We have liftoff 🚀

That pretty much concludes the setup. I also created a personal website as well with the same setup. It was easy enough to do it again. This personal website focuses more on personal and travel-related topics. If you want to take a look https://rikvandenberg.com

To conclude my initial journey:

• Launched a Ghost website
• I'm hosting it on a $5 VM on DigitalOcean
• Bought a domain
• Setup an SSL with the LetsEncrypt integration of Ghost

Feel free to ask any questions or leave a comment. I would love to hear your feedback or interact with you as a reader.

If you are interested in trying this all for yourself or want to try DigitalOcean and see what they've got to offer, you will find an affiliate link below. When you sign up, you will receive $100 of credit for a period of 60 days. After that, if you decide to continue using DigitalOcean, I also receive additional credit.

DigitalOcean – The developer cloud

Helping millions of developers easily build, test, manage, and scale applications of any size – faster than ever before.