Testing

Learning Objectives

• Understand the importance of unit testing, mocking, and integration testing in ASP.NET Core applications.
• Learn how to write unit tests for controllers, services, and repository classes using tools like xUnit or NUnit.
• Use Moq to mock database interactions for isolated testing.
• Learn how to create integration tests to validate end-to-end functionality of your APIs.

Unit Testing

What is Unit Testing? Unit testing is the process of testing small, isolated pieces of code (units), such as methods in a class, to ensure they work as expected. The primary goal of unit testing is to verify that individual units of code function correctly in isolation.

In ASP.NET Core, unit testing is often done for:

• Controllers: To verify the correct response.
• Services: To ensure business logic works correctly.
• Repositories: To ensure data fetching and processing is correct.

Tools Used:

• xUnit or NUnit: Popular testing frameworks used in .NET.
• Moq: A mocking library that helps create mock objects for dependencies.

Example: Unit Testing a Service: Here, we test a service method that fetches a product by ID.

using Xunit;
using Moq;

public class ProductServiceTests
{
    [Fact]
    public void GetProductById_ShouldReturnProduct_WhenProductExists()
    {
        // Arrange
        var mockRepo = new Mock<IProductRepository>();
        mockRepo.Setup(repo => repo.GetProductById(1))
                .Returns(new Product { Id = 1, Name = "Laptop", Price = 1000 });

        var productService = new ProductService(mockRepo.Object);

        // Act
        var product = productService.GetProductById(1);

        // Assert
        Assert.NotNull(product);
        Assert.Equal(1, product.Id);
        Assert.Equal("Laptop", product.Name);
    }
}

• Moq: We use Moq to mock the IProductRepository, allowing us to test the service independently of the database.
• xUnit: The [Fact] attribute indicates that this is a unit test.

Real-Life Example: In an e-commerce system, you may unit test the service that retrieves product information to ensure it handles valid and invalid IDs appropriately.

Mocking Database Interactions

Why Mock Database Interactions? Testing code that interacts directly with a database can be complex and slow. Mocking allows us to isolate the unit of work and simulate database interactions without actually accessing a database.

Using Moq for Repository Mocking:

• Moq is a popular library used to create mock versions of dependencies for testing.

Example: Mocking a Repository: Suppose we have a ProductService that interacts with a repository. We mock the repository to test the AddProduct method.

public class ProductServiceTests
{
    [Fact]
    public void AddProduct_ShouldCallAddMethodOnce()
    {
        // Arrange
        var mockRepo = new Mock<IProductRepository>();
        var productService = new ProductService(mockRepo.Object);
        var product = new Product { Id = 1, Name = "Laptop", Price = 1500.0m };

        // Act
        productService.AddProduct(product);

        // Assert
        mockRepo.Verify(repo => repo.AddProduct(product), Times.Once);
    }
}

Verify: The Verify() method checks if the AddProduct method of the repository was called exactly once, ensuring correct interaction.

Real-Life Example: In a financial application, you might mock a service to ensure that adding a new transaction correctly calls the repository.

Integration Testing

What is Integration Testing? Integration testing is used to verify that multiple components work together as expected. Unlike unit tests, which focus on isolated units of code, integration tests focus on end-to-end behavior, including database, services, and API endpoints.

ASP.NET Core Integration Testing with TestServer:

• ASP.NET Core provides tools to create integration tests using WebApplicationFactory and TestServer.

Example: Integration Test for a Product API: This test ensures that the product API works as expected.

using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc.Testing;
using Xunit;

public class ProductApiIntegrationTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public ProductApiIntegrationTests(WebApplicationFactory<Program> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task GetProductById_ShouldReturnProduct_WhenProductExists()
    {
        // Arrange
        var productId = 1;

        // Act
        var response = await _client.GetAsync($"/api/products/{productId}");

        // Assert
        response.EnsureSuccessStatusCode();
        var responseBody = await response.Content.ReadAsStringAsync();
        Assert.Contains("Laptop", responseBody);
    }
}

• WebApplicationFactory<Program>: Sets up the application for testing, allowing the use of real HTTP calls without starting an external server.
• HttpClient: Used to make requests to the API endpoints and verify the response.

Real-Life Example: In a user management system, you could create an integration test to validate the entire process of creating a new user, fetching user details, and ensuring all the endpoints work together.

Where to Keep Testing Files in an ASP.NET Core Project?

In an ASP.NET Core project, it's best to organize your tests separately from the main application code. Typically, you keep testing files in a separate test project within the solution. Here are the recommended folder structures:

1. Create a Separate Test Project

• Unit Tests and Integration Tests are usually kept in a separate test project. This approach ensures a clear separation between application code and testing code.
• You can create multiple test projects for different kinds of tests. For example:
  • MyApp.Tests.Unit: Contains unit tests.
  • MyApp.Tests.Integration: Contains integration tests.

2. Folder Structure for Tests

If you create a test project, your solution might look like this:

MyApp/
  ├── Controllers/
  ├── Models/
  ├── Services/
  ├── Repositories/
  └── Program.cs

MyApp.Tests.Unit/
  ├── Controllers/
  │    ├── ProductControllerTests.cs
  ├── Services/
  │    ├── ProductServiceTests.cs
  ├── Repositories/
  │    ├── ProductRepositoryTests.cs

MyApp.Tests.Integration/
  ├── IntegrationTests/
  │    ├── ProductApiIntegrationTests.cs

Explanation:

• MyApp.Tests.Unit: Contains all unit tests. You can organize tests into folders that reflect the structure of the main project. For instance, if you are testing ProductService, it should be placed in a Services folder in the test project.
• MyApp.Tests.Integration: Contains integration tests to validate end-to-end workflows.

Creating a Test Project in Visual Studio

1. Right-click the Solution in Solution Explorer.
2. Select Add > New Project.
3. Choose xUnit Test Project or NUnit Test Project from the list of templates.
4. Name it (e.g., MyApp.Tests.Unit).
5. Add references to the main project that you want to test (MyApp).

How to See Test Results?

There are different ways to run tests and view the results in Visual Studio and with command-line tools.

Using Test Explorer in Visual Studio

Visual Studio provides a Test Explorer window where you can see all the test results.

Steps to View Test Results in Test Explorer:

1. Open Test Explorer:
   • Go to Test > Test Explorer in the top menu, or press Ctrl + E, T.
2. Run Tests:
   • You can run all tests by clicking on Run All, or run specific tests by selecting them.
3. View Results:
   • The Test Explorer will display the results—passed, failed, skipped, etc.
   • If a test fails, you can click on it to see the error message and stack trace.

Sample Test Files

1. ProductControllerTests.cs (Unit Test for the Controller)

In this file, we have unit tests for the ProductController class. Typically, we mock the dependencies (in this case, the IProductService) to isolate the tests.

using Xunit;
using Moq;
using Microsoft.AspNetCore.Mvc;
using MyApp.Controllers;
using MyApp.Services;

public class ProductControllerTests
{
    [Fact]
    public void GetProductById_ShouldReturnOk_WhenProductExists()
    {
        // Arrange
        var mockService = new Mock<IProductService>();
        mockService.Setup(service => service.GetProductById(1))
                   .Returns(new Product { Id = 1, Name = "Laptop", Price = 1000 });

        var controller = new ProductController(mockService.Object);

        // Act
        var result = controller.GetProduct(1) as OkObjectResult;

        // Assert
        Assert.NotNull(result);
        Assert.Equal(200, result.StatusCode);
    }

    [Fact]
    public void GetProductById_ShouldReturnNotFound_WhenProductDoesNotExist()
    {
        // Arrange
        var mockService = new Mock<IProductService>();
        mockService.Setup(service => service.GetProductById(999)).Returns((Product)null);

        var controller = new ProductController(mockService.Object);

        // Act
        var result = controller.GetProduct(999);

        // Assert
        Assert.IsType<NotFoundResult>(result);
    }
}

2. ProductServiceTests.cs (Unit Test for the Service)

This file contains tests for the ProductService. We use a mocked repository to ensure that only the business logic of the service is being tested.

using Xunit;
using Moq;
using MyApp.Repositories;
using MyApp.Services;
using MyApp.Models;

public class ProductServiceTests
{
    [Fact]
    public void GetProductById_ShouldReturnProduct_WhenProductExists()
    {
        // Arrange
        var mockRepo = new Mock<IProductRepository>();
        mockRepo.Setup(repo => repo.GetProductById(1))
                .Returns(new Product { Id = 1, Name = "Laptop", Price = 1000 });

        var productService = new ProductService(mockRepo.Object);

        // Act
        var product = productService.GetProductById(1);

        // Assert
        Assert.NotNull(product);
        Assert.Equal(1, product.Id);
        Assert.Equal("Laptop", product.Name);
    }

    [Fact]
    public void AddProduct_ShouldCallAddMethodOnce()
    {
        // Arrange
        var mockRepo = new Mock<IProductRepository>();
        var productService = new ProductService(mockRepo.Object);
        var product = new Product { Id = 1, Name = "Tablet", Price = 500.0m };

        // Act
        productService.AddProduct(product);

        // Assert
        mockRepo.Verify(repo => repo.AddProduct(product), Times.Once);
    }
}

3. ProductRepositoryTests.cs (Unit Test for the Repository)

This file contains tests for the ProductRepository. Typically, repository tests might interact with an in-memory database or a lightweight database for testing.

using Xunit;
using System;
using System.Data.SqlClient;
using MyApp.Repositories;
using MyApp.Models;

public class ProductRepositoryTests
{
    [Fact]
    public void AddProduct_ShouldThrowException_WhenDatabaseUnavailable()
    {
        // Arrange
        string invalidConnectionString = "InvalidConnectionString";
        var repository = new ProductRepository(invalidConnectionString);
        var product = new Product { Name = "Phone", Price = 300.0m };

        // Act & Assert
        Assert.Throws<Exception>(() => repository.AddProduct(product));
    }
}

• In this test, an invalid connection string is provided to simulate a database connection issue, and the test expects an exception to be thrown.

4. ProductApiIntegrationTests.cs (Integration Test for the API Endpoint)

This file contains an integration test that simulates a request to the API to validate end-to-end behavior.

using System.Net.Http;
using System.Text;
using System.Text.Json;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc.Testing;
using Xunit;

public class ProductApiIntegrationTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public ProductApiIntegrationTests(WebApplicationFactory<Program> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task CreateProduct_ShouldReturnCreated_WhenProductIsValid()
    {
        // Arrange
        var product = new { Name = "Smartphone", Price = 800 };
        var content = new StringContent(JsonSerializer.Serialize(product), Encoding.UTF8, "application/json");

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

        // Assert
        Assert.Equal(System.Net.HttpStatusCode.Created, response.StatusCode);
    }
}

Storing Each Test in a Separate File

• Separation of Concerns: Each test class has a single responsibility—testing only the behavior of the respective class it is named after.
• Readability: When each test class is in a separate file, it is easier to navigate the codebase, find specific tests, and maintain them.
• Scaling the Project: As the project grows, storing each test in a separate file helps to organize and scale the test suite without mixing test cases together, leading to more maintainable code.

Examples

Simple Example: Unit Test for Controller Action

Test the GetProductById controller action for a valid product ID.

Code Snippet:

[Fact]
public void GetProductById_ShouldReturnOk_WhenProductExists()
{
    var mockService = new Mock<IProductService>();
    mockService.Setup(service => service.GetProductById(1))
               .Returns(new Product { Id = 1, Name = "Laptop", Price = 1000 });

    var controller = new ProductController(mockService.Object);
    var result = controller.GetProduct(1) as OkObjectResult;

    Assert.NotNull(result);
    Assert.Equal(200, result.StatusCode);
}

Real-Life Example: In an e-commerce system, ensure that the API returns 200 OK for valid product requests.

Simple Example: Mock Repository for AddProduct

Use Moq to verify that a repository's AddProduct method is called.

Code Snippet:

[Fact]
public void AddProduct_ShouldCallRepository()
{
    var mockRepo = new Mock<IProductRepository>();
    var productService = new ProductService(mockRepo.Object);
    var product = new Product { Name = "Tablet", Price = 300 };

    productService.AddProduct(product);

    mockRepo.Verify(repo => repo.AddProduct(product), Times.Once);
}

Real-Life Example: In a financial system, verify that adding a new transaction is processed correctly.

Simple Example: Integration Test for Creating Product

Write an integration test to add a product through the API.

Code Snippet:

[Fact]
public async Task CreateProduct_ShouldReturnCreated_WhenValidProduct()
{
    var product = new { Name = "Smartphone", Price = 800 };
    var content = new StringContent(JsonSerializer.Serialize(product), Encoding.UTF8, "application/json");

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

    Assert.Equal(System.Net.HttpStatusCode.Created, response.StatusCode);
}

Real-Life Example: In an inventory system, validate that new products are created correctly via API endpoints.

Key Takeaways

• Unit Testing: Test small, isolated units of code, such as service methods, to ensure correctness.
• Mocking: Use Moq to create mocks of dependencies, allowing for isolated and reliable testing.
• Integration Testing: Ensure that components work together by testing complete flows, including databases, services, and APIs.

Practical Questions

1. What are the main differences between unit testing and integration testing, and why are both important?
2. How can you use Moq to verify that a service method correctly calls its dependencies?
3. How would you write an integration test to ensure that the entire API works as expected?

New Concepts in .NET 8

New in .NET 8:

• Test Improvements: .NET 8 introduces enhanced tools for integration testing, allowing for easier setup and execution, especially when working with minimal APIs. Integration with Native AOT improves testing for applications that aim to be lightweight and optimized.