Testing ASP.NET Core Applications: Unit and Integration Testing

Building Rock-Solid Applications with Comprehensive Testing Strategies

Testing is the backbone of reliable software development. For ASP.NET Core applications, implementing comprehensive unit and integration testing not only ensures your code functions correctly but also makes maintenance and future development smoother and more predictable.

In this guide, we'll explore practical strategies and best practices for testing your ASP.NET Core applications that you can start using today.

Introduction: Why Testing Matters

When I first started programming, I viewed testing as an afterthought—something to check off the list before deployment. It wasn't until a production disaster (which could have been prevented by proper testing) that I realized testing isn't just important—it's essential.

For ASP.NET Core applications, testing takes on even greater significance. The framework's modular architecture and dependency injection system make it naturally testable, but only if you leverage these features correctly.

Testing provides multiple benefits that directly impact the quality and maintainability of your applications:

• Bug detection before production: Tests catch issues early in the development cycle when they're less expensive to fix.

• Documentation by example: Tests demonstrate how your code should behave and provide living documentation.

• Refactoring safety net: A comprehensive test suite gives you confidence when modifying existing code.

• Design improvement: The testing process often reveals design flaws that might otherwise go unnoticed.

Modern ASP.NET Core applications benefit from two primary types of testing: unit testing (verifying individual components in isolation) and integration testing (ensuring components work together correctly). Let's dive into both approaches.

Unit Testing Fundamentals

What Makes a Good Unit Test?

Unit tests focus on testing a single "unit" of code—typically a method or class—in isolation from its dependencies. Good unit tests follow the "FIRST" principle:

• Fast: Tests should run quickly to encourage developers to run them frequently.

• Isolated: Tests shouldn't depend on each other or external systems.

• Repeatable: Tests should produce the same results each time they run.

• Self-validating: Tests should automatically determine whether they pass or fail.

• Thorough: Tests should cover normal scenarios, edge cases, and error conditions.

In ASP.NET Core, unit testing is facilitated by the framework's design principles, particularly dependency injection, which makes it easier to substitute mock implementations for testing.

Setting Up Your Testing Environment

To get started with unit testing in ASP.NET Core, you'll need a testing framework. The most popular options include:

• xUnit: Modern, extensible, and the testing framework used by the ASP.NET Core team

• NUnit: A mature framework with a rich feature set

• MSTest: Microsoft's built-in testing framework

For this article, we'll focus on xUnit, as it's widely adopted in the ASP.NET Core community.

First, create a test project by adding a new project to your solution. Using the .NET CLI, you can run:

bash
dotnet new xunit -o YourProject.Tests

Next, add a reference to your main project:

bash
dotnet add reference ../YourProject/YourProject.csproj

You'll also need packages for mocking dependencies. Moq is a popular choice:

bash
dotnet add package Moq

Writing Your First Unit Test

Let's start with a simple example. Imagine we have a service that calculates tax:

csharp
public class TaxCalculator
{
    public decimal CalculateTax(decimal amount, decimal rate)
    {
        if (amount < 0)
            throw new ArgumentException("Amount cannot be negative", nameof(amount));
            
        if (rate < 0 || rate > 1)
            throw new ArgumentException("Rate must be between 0 and 1", nameof(rate));
            
        return amount * rate;
    }
}

A unit test for this service might look like:

csharp
public class TaxCalculatorTests
{
    private readonly TaxCalculator _calculator;
    
    public TaxCalculatorTests()
    {
        _calculator = new TaxCalculator();
    }
    
    [Fact]
    public void CalculateTax_WithValidInputs_ReturnsCorrectTax()
    {
        // Arrange
        decimal amount = 100m;
        decimal rate = 0.2m;
        decimal expected = 20m;
        
        // Act
        decimal result = _calculator.CalculateTax(amount, rate);
        
        // Assert
        Assert.Equal(expected, result);
    }
    
    [Fact]
    public void CalculateTax_WithNegativeAmount_ThrowsArgumentException()
    {
        // Arrange
        decimal amount = -100m;
        decimal rate = 0.2m;
        
        // Act & Assert
        var exception = Assert.Throws<ArgumentException>(() => 
            _calculator.CalculateTax(amount, rate));
        Assert.Contains("Amount cannot be negative", exception.Message);
    }
    
    [Theory]
    [InlineData(-0.1)]
    [InlineData(1.1)]
    public void CalculateTax_WithInvalidRate_ThrowsArgumentException(decimal rate)
    {
        // Arrange
        decimal amount = 100m;
        
        // Act & Assert
        Assert.Throws<ArgumentException>(() => 
            _calculator.CalculateTax(amount, rate));
    }
}

This example demonstrates several important aspects of unit testing:

1. The Arrange-Act-Assert pattern structures tests for readability.

2. [Fact] attributes mark individual test methods.

3. [Theory] attributes with [InlineData] enable parametrized tests.

4. Tests cover both successful scenarios and exception cases.

Testing Controllers

Controllers are central to ASP.NET Core MVC applications. Testing them requires special consideration since they interact with HTTP context, routing, and model binding.

Here's an example of a simple controller:

csharp
public class ProductsController : Controller
{
    private readonly IProductRepository _repository;
    
    public ProductsController(IProductRepository repository)
    {
        _repository = repository;
    }
    
    public async Task<IActionResult> Index()
    {
        var products = await _repository.GetAllAsync();
        return View(products);
    }
    
    [HttpGet]
    public IActionResult Create()
    {
        return View();
    }
    
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Create(ProductViewModel product)
    {
        if (!ModelState.IsValid)
            return View(product);
            
        await _repository.AddAsync(new Product
        {
            Name = product.Name,
            Price = product.Price
        });
        
        return RedirectToAction(nameof(Index));
    }
}

To test this controller, we use mocks to isolate it from its dependencies:

csharp
public class ProductsControllerTests
{
    private readonly Mock<IProductRepository> _mockRepository;
    private readonly ProductsController _controller;
    
    public ProductsControllerTests()
    {
        _mockRepository = new Mock<IProductRepository>();
        _controller = new ProductsController(_mockRepository.Object);
    }
    
    [Fact]
    public async Task Index_ReturnsViewWithProducts()
    {
        // Arrange
        var products = new List<Product>
        {
            new Product { Id = 1, Name = "Product 1", Price = 10.99m },
            new Product { Id = 2, Name = "Product 2", Price = 20.99m }
        };
        
        _mockRepository.Setup(repo => repo.GetAllAsync())
            .ReturnsAsync(products);
        
        // Act
        var result = await _controller.Index();
        
        // Assert
        var viewResult = Assert.IsType<ViewResult>(result);
        var model = Assert.IsAssignableFrom<IEnumerable<Product>>(viewResult.Model);
        Assert.Equal(2, model.Count());
    }
    
    [Fact]
    public async Task Create_Post_WithValidModel_RedirectsToIndex()
    {
        // Arrange
        var product = new ProductViewModel { Name = "New Product", Price = 15.99m };
        
        _mockRepository.Setup(repo => repo.AddAsync(It.IsAny<Product>()))
            .Returns(Task.CompletedTask);
        
        // Act
        var result = await _controller.Create(product);
        
        // Assert
        var redirectResult = Assert.IsType<RedirectToActionResult>(result);
        Assert.Equal("Index", redirectResult.ActionName);
        
        _mockRepository.Verify(repo => 
            repo.AddAsync(It.Is<Product>(p => 
                p.Name == product.Name && p.Price == product.Price)), 
            Times.Once);
    }
    
    [Fact]
    public async Task Create_Post_WithInvalidModel_ReturnsViewWithModel()
    {
        // Arrange
        var product = new ProductViewModel { Name = "", Price = -1m };
        _controller.ModelState.AddModelError("Name", "Required");
        
        // Act
        var result = await _controller.Create(product);
        
        // Assert
        var viewResult = Assert.IsType<ViewResult>(result);
        var model = Assert.IsType<ProductViewModel>(viewResult.Model);
        Assert.Equal(product, model);
        
        _mockRepository.Verify(repo => repo.AddAsync(It.IsAny<Product>()), Times.Never);
    }
}

This example shows how to:

1. Use Moq to create mock dependencies

2. Test different action results (ViewResult, RedirectToActionResult)

3. Verify interactions with dependencies

4. Test model validation scenarios

Testing API Controllers

API controllers have some differences from MVC controllers. They return data rather than views and often work with different return types:

csharp
[ApiController]
[Route("api/[controller]")]
public class ProductsApiController : ControllerBase
{
    private readonly IProductRepository _repository;
    
    public ProductsApiController(IProductRepository repository)
    {
        _repository = repository;
    }
    
    [HttpGet]
    public async Task<ActionResult<IEnumerable<Product>>> GetAll()
    {
        return await _repository.GetAllAsync();
    }
    
    [HttpGet("{id}")]
    public async Task<ActionResult<Product>> Get(int id)
    {
        var product = await _repository.GetByIdAsync(id);
        
        if (product == null)
            return NotFound();
            
        return product;
    }
    
    [HttpPost]
    public async Task<ActionResult<Product>> Create(Product product)
    {
        await _repository.AddAsync(product);
        return CreatedAtAction(nameof(Get), new { id = product.Id }, product);
    }
}

Testing this API controller would look like:

csharp
public class ProductsApiControllerTests
{
    private readonly Mock<IProductRepository> _mockRepository;
    private readonly ProductsApiController _controller;
    
    public ProductsApiControllerTests()
    {
        _mockRepository = new Mock<IProductRepository>();
        _controller = new ProductsApiController(_mockRepository.Object);
    }
    
    [Fact]
    public async Task GetAll_ReturnsAllProducts()
    {
        // Arrange
        var products = new List<Product>
        {
            new Product { Id = 1, Name = "Product 1", Price = 10.99m },
            new Product { Id = 2, Name = "Product 2", Price = 20.99m }
        };
        
        _mockRepository.Setup(repo => repo.GetAllAsync())
            .ReturnsAsync(products);
        
        // Act
        var result = await _controller.GetAll();
        
        // Assert
        var actionResult = Assert.IsType<ActionResult<IEnumerable<Product>>>(result);
        var returnValue = Assert.IsAssignableFrom<IEnumerable<Product>>(actionResult.Value);
        Assert.Equal(2, returnValue.Count());
    }
    
    [Fact]
    public async Task Get_WithExistingId_ReturnsProduct()
    {
        // Arrange
        var product = new Product { Id = 1, Name = "Product 1", Price = 10.99m };
        
        _mockRepository.Setup(repo => repo.GetByIdAsync(1))
            .ReturnsAsync(product);
        
        // Act
        var result = await _controller.Get(1);
        
        // Assert
        var actionResult = Assert.IsType<ActionResult<Product>>(result);
        var returnValue = Assert.IsType<Product>(actionResult.Value);
        Assert.Equal(product.Id, returnValue.Id);
        Assert.Equal(product.Name, returnValue.Name);
    }
    
    [Fact]
    public async Task Get_WithNonExistingId_ReturnsNotFound()
    {
        // Arrange
        _mockRepository.Setup(repo => repo.GetByIdAsync(999))
            .ReturnsAsync((Product)null);
        
        // Act
        var result = await _controller.Get(999);
        
        // Assert
        var actionResult = Assert.IsType<ActionResult<Product>>(result);
        Assert.IsType<NotFoundResult>(actionResult.Result);
    }
    
    [Fact]
    public async Task Create_ReturnsCreatedAtAction()
    {
        // Arrange
        var product = new Product { Name = "New Product", Price = 15.99m };
        var savedProduct = new Product { Id = 1, Name = "New Product", Price = 15.99m };
        
        _mockRepository.Setup(repo => repo.AddAsync(It.IsAny<Product>()))
            .Callback<Product>(p => p.Id = 1)
            .Returns(Task.CompletedTask);
        
        // Act
        var result = await _controller.Create(product);
        
        // Assert
        var actionResult = Assert.IsType<ActionResult<Product>>(result);
        var createdAtActionResult = Assert.IsType<CreatedAtActionResult>(actionResult.Result);
        
        Assert.Equal("Get", createdAtActionResult.ActionName);
        Assert.Equal(1, createdAtActionResult.RouteValues["id"]);
        
        var returnValue = Assert.IsType<Product>(createdAtActionResult.Value);
        Assert.Equal(1, returnValue.Id);
        Assert.Equal(product.Name, returnValue.Name);
    }
}

These tests demonstrate how to verify:

1. Different API-specific result types (NotFoundResult, CreatedAtActionResult)

2. Status codes and response content

3. Route value parameters

Integration Testing

While unit tests are valuable, they can't verify that your components work together correctly in a real application. That's where integration testing comes in.

Understanding Integration Testing in ASP.NET Core

Integration tests in ASP.NET Core typically use the TestServer class, which can host your application in memory for testing. This approach allows you to:

• Test the entire request pipeline

• Verify routing, middleware, filters, and controllers

• Test actual database interactions (with a test database)

• Validate authentication and authorization

The Microsoft.AspNetCore.Mvc.Testing package provides a WebApplicationFactory class that simplifies integration testing by creating a TestServer with your application configuration.

Setting Up Integration Tests

First, add the required package to your test project:

bash
dotnet add package Microsoft.AspNetCore.Mvc.Testing

Then create a custom WebApplicationFactory:

csharp
public class CustomWebApplicationFactory<TStartup> 
    : WebApplicationFactory<TStartup> where TStartup : class
{
    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.ConfigureServices(services =>
        {
            // Remove the app's ApplicationDbContext registration.
            var descriptor = services.SingleOrDefault(
                d => d.ServiceType ==
                    typeof(DbContextOptions<ApplicationDbContext>));

            if (descriptor != null)
            {
                services.Remove(descriptor);
            }

            // Add ApplicationDbContext using an in-memory database for testing.
            services.AddDbContext<ApplicationDbContext>(options =>
            {
                options.UseInMemoryDatabase("InMemoryTestDb");
            });

            // Build the service provider.
            var sp = services.BuildServiceProvider();

            // Create a scope to obtain a reference to the database context
            using (var scope = sp.CreateScope())
            {
                var scopedServices = scope.ServiceProvider;
                var db = scopedServices.GetRequiredService<ApplicationDbContext>();

                // Ensure the database is created.
                db.Database.EnsureCreated();

                // Seed the database with test data.
                SeedTestData(db);
            }
        });
    }

    private void SeedTestData(ApplicationDbContext db)
    {
        db.Products.Add(new Product { Id = 1, Name = "Test Product 1", Price = 9.99m });
        db.Products.Add(new Product { Id = 2, Name = "Test Product 2", Price = 19.99m });
        db.SaveChanges();
    }
}

This factory configures a test environment with:

1. An in-memory database instead of your actual database

2. Test data for consistent test results

3. Any other service substitutions needed for testing

Writing Integration Tests

Now let's write an integration test that verifies a complete HTTP request:

csharp
public class ProductsIntegrationTests : IClassFixture<CustomWebApplicationFactory<Startup>>
{
    private readonly HttpClient _client;

    public ProductsIntegrationTests(CustomWebApplicationFactory<Startup> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task GetAllProducts_ReturnsSuccessAndCorrectContentType()
    {
        // Act
        var response = await _client.GetAsync("/api/products");

        // Assert
        response.EnsureSuccessStatusCode(); // Status code 200-299
        Assert.Equal("application/json; charset=utf-8", 
            response.Content.Headers.ContentType.ToString());
    }

    [Fact]
    public async Task GetAllProducts_ReturnsExpectedProducts()
    {
        // Act
        var response = await _client.GetAsync("/api/products");

        // Assert
        response.EnsureSuccessStatusCode();
        
        var stringResponse = await response.Content.ReadAsStringAsync();
        var products = JsonSerializer.Deserialize<List<Product>>(stringResponse, 
            new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
        
        Assert.Equal(2, products.Count);
        Assert.Contains(products, p => p.Id == 1);
        Assert.Contains(products, p => p.Id == 2);
    }

    [Fact]
    public async Task GetProduct_WithValidId_ReturnsProduct()
    {
        // Act
        var response = await _client.GetAsync("/api/products/1");

        // Assert
        response.EnsureSuccessStatusCode();
        
        var stringResponse = await response.Content.ReadAsStringAsync();
        var product = JsonSerializer.Deserialize<Product>(stringResponse, 
            new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
        
        Assert.Equal(1, product.Id);
        Assert.Equal("Test Product 1", product.Name);
    }

    [Fact]
    public async Task GetProduct_WithInvalidId_ReturnsNotFound()
    {
        // Act
        var response = await _client.GetAsync("/api/products/999");

        // Assert
        Assert.Equal(HttpStatusCode.NotFound, response.StatusCode);
    }

    [Fact]
    public async Task CreateProduct_ReturnsCreatedAndNewProduct()
    {
        // Arrange
        var newProduct = new Product { Name = "New Test Product", Price = 29.99m };
        var content = new StringContent(
            JsonSerializer.Serialize(newProduct),
            Encoding.UTF8,
            "application/json");

        // Act
        var response = await _client.PostAsync("/api/products", content);

        // Assert
        Assert.Equal(HttpStatusCode.Created, response.StatusCode);
        
        var stringResponse = await response.Content.ReadAsStringAsync();
        var product = JsonSerializer.Deserialize<Product>(stringResponse, 
            new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
        
        Assert.Equal(newProduct.Name, product.Name);
        Assert.Equal(newProduct.Price, product.Price);
        Assert.NotEqual(0, product.Id); // ID should be assigned
        
        // Verify Location header
        Assert.Contains($"/api/products/{product.Id}", 
            response.Headers.GetValues("Location").First());
    }
}

These tests demonstrate:

1. Making HTTP requests to your API endpoints

2. Verifying status codes and headers

3. Deserializing and validating response content

4. Testing both successful and error scenarios

Testing Authentication and Authorization

For applications with authentication, you'll need to simulate authenticated requests in your tests:

csharp
public class AuthenticatedIntegrationTests : IClassFixture<CustomWebApplicationFactory<Startup>>
{
    private readonly HttpClient _client;

    public AuthenticatedIntegrationTests(CustomWebApplicationFactory<Startup> factory)
    {
        _client = factory.CreateClient(new WebApplicationFactoryClientOptions
        {
            AllowAutoRedirect = false
        });

        // Add auth headers
        _client.DefaultRequestHeaders.Authorization = 
            new AuthenticationHeaderValue("Bearer", "TestToken");
    }

    [Fact]
    public async Task SecureEndpoint_WithValidToken_ReturnsSuccess()
    {
        // Configure test auth in factory...
        
        // Act
        var response = await _client.GetAsync("/api/secure-resource");

        // Assert
        response.EnsureSuccessStatusCode();
    }
}

For more complex authentication scenarios, you'll need to configure your CustomWebApplicationFactory to use a mock authentication handler.

Testing Best Practices and Advanced Techniques

Test Organization

As your test suite grows, organization becomes crucial. Consider the following structure:

1. Arrange: Set up the test conditions

2. Act: Execute the code under test

3. Assert: Verify the results

Additionally, group related tests using nested classes or by feature area:

csharp
public class ProductControllerTests
{
    public class GetTests : ProductControllerTestBase { /* Get method tests */ }
    public class CreateTests : ProductControllerTestBase { /* Create method tests */ }
    public class UpdateTests : ProductControllerTestBase { /* Update method tests */ }
    public class DeleteTests : ProductControllerTestBase { /* Delete method tests */ }
}

Effective Test Naming

Clear test names help you understand what's being tested and what to expect:

[Method_Under_Test]_[Scenario]_[Expected_Result]

For example:

• Get_WithValidId_ReturnsProduct

• Create_WithInvalidModel_ReturnsBadRequest

Test Data Management

For complex test data, consider using:

1. Object Mothers: Classes that create common test objects

2. Builder Pattern: Fluent interfaces for constructing test objects

3. AutoFixture: A library to automatically generate test data

For example, an Object Mother for products:

csharp
public static class ProductMother
{
    public static Product Standard()
    {
        return new Product
        {
            Id = 1,
            Name = "Standard Product",
            Price = 19.99m,
            Description = "A standard product for testing"
        };
    }
    
    public static Product WithCustomPrice(decimal price)
    {
        var product = Standard();
        product.Price = price;
        return product;
    }
}

Testing Async Code

ASP.NET Core makes heavy use of async/await. Ensure your tests properly handle async code:

1. Mark test methods with async

2. Return Task from test methods

3. Use async versions of assertion methods when available

4. Be cautious with .Result or .Wait() which can cause deadlocks

Snapshot Testing

For complex outputs, consider snapshot testing. This approach compares the current output to a previously saved "snapshot" of expected output.

Testing Middleware

Middleware components can be tested both in isolation and as part of the request pipeline:

csharp
[Fact]
public async Task CustomMiddleware_AddsExpectedHeader()
{
    // Arrange
    var context = new DefaultHttpContext();
    var nextMiddleware = new RequestDelegate(_ => Task.CompletedTask);
    var middleware = new CustomHeaderMiddleware(nextMiddleware);
    
    // Act
    await middleware.Invoke(context);
    
    // Assert
    Assert.True(context.Response.Headers.ContainsKey("X-Custom-Header"));
    Assert.Equal("TestValue", context.Response.Headers["X-Custom-Header"]);
}

Testing Blazor Components

For Blazor applications, you can test components using bUnit:

csharp
[Fact]
public void Counter_ClickButton_IncrementsCount()
{
    // Arrange
    using var ctx = new TestContext();
    var cut = ctx.RenderComponent<Counter>();
    var countDisplay = cut.Find("p");
    
    // Act
    cut.Find("button").Click();
    
    // Assert
    countDisplay.MarkupMatches("<p>Current count: 1</p>");
}

Common Testing Challenges and Solutions

Dealing with External Dependencies

When your code interacts with external systems like databases, APIs, or file systems, you have several options:

1. Mocking: Replace external dependencies with test doubles

2. Integration Tests: Use real but controlled instances (like in-memory databases)

3. Test Containers: Use Docker containers for more realistic environments

Testing Database Access

Entity Framework Core provides an in-memory database provider that's useful for testing:

csharp
[Fact]
public async Task GetAllProducts_ReturnsAllProducts()
{
    // Arrange
    var options = new DbContextOptionsBuilder<ApplicationDbContext>()
        .UseInMemoryDatabase(databaseName: "TestDatabase")
        .Options;
    
    // Seed the database
    using (var context = new ApplicationDbContext(options))
    {
        context.Products.Add(new Product { Id = 1, Name = "Test Product 1", Price = 9.99m });
        context.Products.Add(new Product { Id = 2, Name = "Test Product 2", Price = 19.99m });
        context.SaveChanges();
    }
    
    // Act
    using (var context = new ApplicationDbContext(options))
    {
        var repository = new ProductRepository(context);
        var products = await repository.GetAllAsync();
        
        // Assert
        Assert.Equal(2, products.Count());
    }
}

For more realistic tests, consider using SQLite in-memory or Docker containers with actual database images.

Testing Configuration

Configure your test environment with appropriate settings:

csharp
public class ConfigurationTests
{
    [Fact]
    public void ConfigureOptions_WithValidConfiguration_SetsCorrectValues()
    {
        // Arrange
        var configuration = new ConfigurationBuilder()
            .AddInMemoryCollection(new Dictionary<string, string>
            {
                ["MyOptions:Setting1"] = "Value1",
                ["MyOptions:Setting2"] = "42"
            })
            .Build();
        
        var services = new ServiceCollection();
        services.Configure<MyOptions>(configuration.GetSection("MyOptions"));
        var serviceProvider = services.BuildServiceProvider();
        
        // Act
        var options = serviceProvider.GetRequiredService<IOptions<MyOptions>>().Value;
        
        // Assert
        Assert.Equal("Value1", options.Setting1);
        Assert.Equal(42, options.Setting2);
    }
}

Handling Time-Dependent Tests

For code that depends on the current time, create a time provider abstraction:

csharp
public interface ITimeProvider
{
    DateTime UtcNow { get; }
}

// In production
public class SystemTimeProvider : ITimeProvider
{
    public DateTime UtcNow => DateTime.UtcNow;
}

// In tests
public class FakeTimeProvider : ITimeProvider
{
    public DateTime UtcNow { get; set; } = new DateTime(2023, 1, 1);
}

Then you can control time in your tests:

csharp
[Fact]
public void ExpiredItem_ReturnsTrue_WhenPastExpiryDate()
{
    // Arrange
    var fakeTime = new FakeTimeProvider { UtcNow = new DateTime(2023, 6, 1) };
    var item = new Item { ExpiryDate = new DateTime(2023, 5, 31) };
    var service = new ItemService(fakeTime);
    
    // Act
    bool isExpired = service.IsExpired(item);
    
    // Assert
    Assert.True(isExpired);
}

Test-Driven Development with ASP.NET Core

Test-Driven Development (TDD) is a development approach where you write tests before implementing features. The cycle is:

1. Write a failing test

2. Write just enough code to make the test pass

3. Refactor the code while keeping tests passing

TDD works particularly well with ASP.NET Core due to the framework's testability. Here's a simple example:

1. First, write a test for a feature that doesn't exist yet:

csharp
[Fact]
public async Task GetDiscountedProducts_ReturnsOnlyDiscountedItems()
{
    // Arrange
    var mockRepository = new Mock<IProductRepository>();
    mockRepository.Setup(repo => repo.GetAllAsync()).ReturnsAsync(new List<Product>
    {
        new Product { Id = 1, Name = "Regular Product", Price = 10.0m, Discount = 0.0m },
        new Product { Id = 2, Name = "Discounted Product", Price = 20.0m, Discount = 0.5m }
    });
    
    var controller = new ProductsApiController(mockRepository.Object);
    
    // Act
    var result = await controller.GetDiscountedProducts();
    
    // Assert
    var actionResult = Assert.IsType<ActionResult<IEnumerable<Product>>>(result);
    var products = Assert.IsAssignableFrom<IEnumerable<Product>>(actionResult.Value);
    
    Assert.Single(products);
    Assert.Equal(2, products.First().Id);
}

2. Implement the feature to make the test pass:

csharp
[HttpGet("discounted")]
public async Task<ActionResult<IEnumerable<Product>>> GetDiscountedProducts()
{
    var allProducts = await _repository.GetAllAsync();
    return allProducts.Where(p => p.Discount > 0).ToList();
}

3. Refactor if necessary while ensuring tests still pass

TDD can help you:

• Focus on requirements first

• Write more testable code

• Build a comprehensive test suite as you develop

• Refactor with confidence

Measuring Test Coverage

Test coverage helps you identify untested parts of your code. Tools like Coverlet can integrate with your test projects:

bash
dotnet add package coverlet.collector
dotnet add package coverlet.msbuild

Then run tests with coverage:

bash
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura

Use ReportGenerator to visualize coverage:

bash
dotnet tool install -g dotnet-reportgenerator-globaltool
reportgenerator -reports:./coverage.cobertura.xml -targetdir:./coverage-report

Aim for high coverage but remember that coverage doesn't guarantee quality—you need meaningful assertions too.

Continuous Integration and Testing

Integrate testing into your CI/CD pipeline to ensure tests run on every code change:

yaml
# Azure DevOps example
trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '8.0.x'
- script: dotnet restore
  displayName: 'Restore NuGet packages'
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'Build the project'
- script: dotnet test --configuration $(buildConfiguration) --no-build --collect:"XPlat Code Coverage"
  displayName: 'Run tests with coverage'
- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Build.SourcesDirectory)/**/coverage.cobertura.xml'

With this pipeline, tests run automatically on each push, and the results are available in your CI system.

Testing Performance and Load

Performance testing ensures your application can handle expected loads. For ASP.NET Core applications, consider:

1. JMeter or k6: For HTTP-based load testing

2. BenchmarkDotNet: For precise micro-benchmarks

3. Application Insights: For real-world performance monitoring

A simple BenchmarkDotNet test might look like:

csharp
[MemoryDiagnoser]
public class PerformanceTests
{
    private readonly TaxCalculator _calculator = new TaxCalculator();
    
    [Benchmark]
    public decimal CalculateTax_Standard()
    {
        return _calculator.CalculateTax(100m, 0.2m);
    }
    
    [Benchmark]
    public decimal CalculateTax_WithLargeAmount()
    {
        return _calculator.CalculateTax(1000000m, 0.2m);
    }
}

Run with:

bash
dotnet run -c Release --project YourBenchmarkProject.csproj

Debugging Failed Tests

When tests fail, you need efficient debugging strategies:

1. Clear error messages: Use descriptive assertions that explain what's wrong

2. Logging: Add temporary logging to see intermediate values

3. Test isolation: Run just the failing test to focus your debugging

4. Visual Studio Test Explorer: Use the debugger to step through test execution

5. Correlation IDs: In integration tests, trace requests through your system

Refactoring Tests

As your application evolves, tests need maintenance too:

1. Extract common setup: Use constructor, class fixtures, or helper methods

2. Parameterize similar tests: Convert multiple similar tests into a single parameterized test

3. Update assertions: Refine expectations as requirements change

4. Remove duplication: Apply DRY principles to test code just like production code

Conclusion: Building a Testing Culture

Testing is not just a technical practice but a cultural one. To build an effective testing culture:

1. Make testing a requirement: No feature is complete without tests

2. Test first when possible: Consider TDD for critical components

3. Review tests during code reviews: Ensure tests are thorough and maintainable

4. Celebrate test improvements: Recognize team members who enhance the test suite

5. Fix failing tests immediately: Treat a failing test as a high-priority bug

In ASP.NET Core applications, testing isn't optional—it's essential for maintaining quality as your application grows. By combining unit tests for detailed component verification with integration tests for system-level validation, you create a comprehensive testing strategy that catches issues early and builds confidence in your codebase.

Remember, the goal isn't just to achieve high test coverage but to create meaningful tests that verify your application behaves correctly in all scenarios. With the testing approaches and patterns we've explored, you're well-equipped to build robust, reliable ASP.NET Core applications that stand the test of time.

Join The Community!

If you found this article helpful, consider subscribing to ASP Today for more in-depth content on ASP.NET Core development. Join our community on Substack Chat to connect with fellow developers, ask questions, and share your experiences.

By subscribing, you'll get direct access to:

• Weekly articles on ASP.NET Core best practices

• Code examples and templates

• Early access to tutorials and guides

• A supportive community of ASP.NET developers

Don't miss out on the opportunity to level up your ASP.NET Core skills. Subscribe today and become part of our growing community!