Unit Testing Service Layer in ASP.NET Core Web API

Back to: ASP.NET Core Web API Tutorials

Unit Testing Service Layer in ASP.NET Core Web API

In this article, I will discuss Unit Testing Service Layer in ASP.NET Core Web API with Examples. Please read our previous article, which discusses the Real-time ASP.NET Core Project Development for Unit Testing. In a typical layered ASP.NET Core Web API application, the architecture is organized into three primary layers:

• Presentation Layer (Controllers): Handles HTTP requests, performs basic input validation, and calls the service layer. Focus on HTTP-specific concerns, such as routing, status codes, and response formatting.
• Business Logic Layer (Services): Sits between Controllers and Data Access Layer. It contains the business logic, rules, and transactional workflows.
• Data Access Layer (Repositories/DbContext): Interacts with the database; performs CRUD operations. Focuses purely on data persistence without business logic.

What Does the Service Layer Contain?

The Service Layer is more than a pass-through to repositories. For a better understanding of the Service Layer’s Role and Responsibilities, please refer to the following diagram.

Managing Multiple Repositories

In many scenarios, a single operation involves coordinating several repositories. For example, an OrderService might need to:

• Use IOrderRepository to create and retrieve order data.
• Use IProductRepository to verify product availability, stock levels, and pricing.
• Use ICustomerRepository to validate customer information and preferences.

By managing these multiple repositories together, the Service Layer ensures that complex business processes, such as placing an order that involves checking stock, updating inventory, and recording customer data, complete smoothly and consistently.

Enforcing Business Rules

The Service Layer is responsible for implementing domain-specific rules that define how your application behaves, for example:

• Discount Calculations: Applying discounts dynamically based on order size, customer loyalty status, or ongoing promotions.
• Stock Validations: Preventing orders that exceed available stock and updating inventory after successful purchases.
• Input Validations: Going beyond simple input checks to verify domain constraints such as customer credit limits or product eligibility.
• Tax and Shipping Charges: Calculating and applying taxes and shipping fees in accordance with business policies.

Handling Transactions

The Service Layer manages transactional consistency by ensuring that multiple operations either all succeed or all fail together. For example:

• When an order is created, steps like checking product availability, inserting order records, and updating stock levels are treated as a single atomic unit. If any step fails, the entire operation rolls back to maintain data integrity.
• This transactional handling prevents partial updates that could leave your system in an inconsistent state.

Why Unit Testing the Service Layer is Important

Let’s understand why it’s important to Unit Test the service layer in isolation. Please have a look at the following diagram.

Central Logic Location

The Service Layer encapsulates all essential business decisions and calculations. Because it holds the rules (e.g., discount thresholds, stock updates), unit testing ensures these rules are implemented correctly and continue to behave as expected as your application evolves.

Early Bug Detection

Most real-world bugs arise from flaws in business logic rather than from controllers or database infrastructure. Unit tests help detect these issues early in the development cycle, avoiding costly and complicated fixes after deployment.

Isolation Testing

Testing the Service Layer in isolation allows you to focus purely on business logic without the noise of HTTP or database details. Using mocking or in-memory databases:

• Speeds up test execution by removing dependencies on network or I/O.
• Improves reliability by eliminating flaky tests caused by external systems.
• Simplifies debugging by pinpointing failures directly within business rules.

Facilitates Easy Refactoring

Because these unit tests are fast and reliable, developers can confidently refactor and optimize business logic. Unit tests provide immediate feedback, ensuring that new changes don’t break existing functionality.

What Are Mocks?

Mocks are the fake objects that implement the same interfaces as real dependencies but behave in a controlled and predictable manner:

• They do not interact with databases or external systems.
• They return predefined data or throw exceptions as configured.
• They allow you to simulate different scenarios and edge cases without a complex setup.

For a better understanding, please have a look at the following diagram:

By using mocks, we gain precise control over how our service interacts with its dependencies, enabling thorough and isolated testing of our business logic.

Different Approaches to Testing the Service Layer in ASP.NET Core Web API

There are two common strategies to unit test the service layer, each with its own advantages. They are as follows:

• Using an In-Memory Database with Real Repositories
• Using Mocking Frameworks (e.g., Moq)

Using an In-Memory Database with Real Repositories

• Employs EF Core’s InMemory database provider to simulate a real database in memory.
• Uses actual repository implementations backed by this in-memory context.
• Allows realistic testing of repository queries, entity tracking, and relationships.
• Best suited for integration-style tests that validate end-to-end data flow with minimal external dependencies.

Note: This approach is closer to production behaviour but may still differ in some SQL-specific features and constraints.

Using Mocking Frameworks (e.g., Moq)

• Creates mocks of repository interfaces that return predefined results.
• Enables full isolation of the Service Layer by eliminating all data access concerns.
• Simplifies testing error scenarios, timeouts, or exceptions that are hard to replicate with in-memory databases.
• Results in faster, more focused tests specifically targeting business logic.

Adding Necessary NuGet Packages

• To use EF Core InMemory provider: Install-Package Microsoft.EntityFrameworkCore.InMemory
• To use Moq mocking framework: Install-Package Moq

Example to Understand Unit Tests with In-Memory Database Setup

Create a class file named OrderServiceUnitTests.cs within the Services folder of ProductCatalog.Tests project, and then copy and paste the following code. In the below code, the BuildTestContextAndService() method:

• Creates a brand-new in-memory ApplicationDbContext.
• Seeds exactly two products and one customer.
• Instantiates real repository classes (OrderRepository, ProductRepository, CustomerRepository) against that context.
• Constructs the OrderService that we want to test.

The following code is self-explained, so please read the comment lines for a better understanding.

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Diagnostics;
using ProductCatalog.API.Data;
using ProductCatalog.API.DTOs;
using ProductCatalog.API.Exceptions;
using ProductCatalog.API.Models;
using ProductCatalog.API.Repositories;
using ProductCatalog.API.Services;

namespace ProductCatalog.Tests.Services
{
    public class OrderServiceUnitTests
    {
        // Creates a fresh in-memory ApplicationDbContext with seeded products and customers,
        // then returns that context plus a newly built OrderService that uses real repositories.
        private (ApplicationDbContext db, IOrderService service) BuildTestContextAndService()
        {
            // Configure EF Core to use an in-memory database with a unique name:
            //    - Guid.NewGuid() ensures each test gets its own database instance.
            //    - ConfigureWarnings(...) suppresses the "TransactionIgnoredWarning" since InMemory does not support real transactions.
            var dbOptions = new DbContextOptionsBuilder<ApplicationDbContext>()
                .UseInMemoryDatabase($"OrderServiceTestDb_{Guid.NewGuid()}")
                .ConfigureWarnings(cfg => cfg.Ignore(InMemoryEventId.TransactionIgnoredWarning))
                .Options;

            // Instantiate the in-memory DbContext with the configured options.
            var dbContext = new ApplicationDbContext(dbOptions);

            // Seed test products into the in-memory DbContext.
            //    - Product 1: TestProductA, Price=100, Stock=5
            //    - Product 2: TestProductB, Price=200, Stock=2
            dbContext.Products.AddRange(
                new Product { Id = 1, Name = "TestProductA", Price = 100m, Stock = 5 },
                new Product { Id = 2, Name = "TestProductB", Price = 200m, Stock = 2 }
            );

            // Seed a test customer into the in-memory DbContext.
            //    - Customer 1: TestCustomer
            dbContext.Customers.Add(
                new Customer { Id = 1, Name = "TestCustomer", Email = "test@sample.com" }
            );

            // Persist the seeded data to the in-memory database.
            dbContext.SaveChanges();

            // Instantiate Real repository classes that use this in-memory DbContext.
            //    - These repositories behave exactly as in production, but against our in-memory store.
            var orderRepo = new OrderRepository(dbContext);
            var productRepo = new ProductRepository(dbContext);
            var customerRepo = new CustomerRepository(dbContext);

            // Create and return the OrderService under test, passing it the real repositories.
            var service = new OrderService(orderRepo, productRepo, customerRepo);

            return (dbContext, service);
        }
    }
}

Unit Test for Successful Order Creation

• Sets up the in-memory database and service
• Creates a valid order (with sufficient stock, existing products/customer)
• Checks that the order is created as expected (correct customer, order items, amounts, and stock deduction)

Example: Create an order for Customer 1 with two items:

• Product 1, Quantity = 2 (stock was 5)
• Product 2, Quantity = 1 (stock was 2)
• Total base = (2×100) + (1×200) = ₹400, which is below the ₹5000 discount threshold → Discount = ₹0.

Please add the following method to the OrderServiceUnitTests class. The following code is self-explained, so please read the comment lines for a better understanding.

[Fact]
public async Task CreateOrderAsync_WithValidInput_ReturnsOrderResponse()
{
    // Arrange: get a brand-new in-memory context + OrderService
    var (dbContext, orderService) = BuildTestContextAndService();

    // Prepare a valid OrderCreateDTO:
    //  - CustomerId = 1 (exists in seeded data)
    //  - Two items: (ProductId=1, Quantity=2) and (ProductId=2, Quantity=1).
    var validOrderDto = new OrderCreateDTO
    {
        CustomerId = 1,
        Items = new List<OrderItemDTO>
        {
            new() { ProductId = 1, Quantity = 2 }, // TestProductA, stock = 5
            new() { ProductId = 2, Quantity = 1 }  // TestProductB, stock = 2
        }
    };

    // Act: attempt to create the order using the service under test
    var orderResponse = await orderService.CreateOrderAsync(validOrderDto);

    // Assert: the returned DTO is not null (order was created successfully)
    Assert.NotNull(orderResponse);

    // The returned DTO should have CustomerId = 1
    Assert.Equal(1, orderResponse.CustomerId);

    // There should be 2 items in the OrderResponseDTO
    Assert.Equal(2, orderResponse.OrderItems.Count);

    // Calculate the expected base amount: (2 × 100m) + (1 × 200m) = 400m
    var expectedBase = (2 * 100m) + (1 * 200m);
    Assert.Equal(expectedBase, orderResponse.BaseAmount);

    // Because 400m < 5000m, no discount should have been applied
    Assert.Equal(0m, orderResponse.Discount);

    // TotalAmount = BaseAmount − Discount = 400m − 0m = 400m
    Assert.Equal(expectedBase, orderResponse.TotalAmount);

    // Now verify that the in-memory database’s stock was actually updated:
    //  - ProductId=1 originally had stock=5; after ordering 2, new stock should be 3
    var product1 = await dbContext.Products.FindAsync(1);
    Assert.Equal(3, product1?.Stock);

    //  - ProductId=2 originally had stock=2; after ordering 1, new stock should be 1
    var product2 = await dbContext.Products.FindAsync(2);
    Assert.Equal(1, product2?.Stock);
}

Unit Test for Product Not Found

Tries to create an order for a product that doesn’t exist in the DB and expects a NotFoundException to be thrown. So, please add the following method inside OrderServiceUnitTests class. The following code is self-explained, so please read the comment lines for a better understanding.

[Fact]
public async Task CreateOrderAsync_ProductMissing_ThrowsNotFoundException()
{
    // Arrange: get a fresh context + service
    var (dbContext, orderService) = BuildTestContextAndService();

    // Build an OrderCreateDTO where ProductId = 999 (does not exist in seeded data)
    var invalidProductDto = new OrderCreateDTO
    {
        CustomerId = 1,
        Items = new List<OrderItemDTO>
        {
            new() { ProductId = 999, Quantity = 1 }
        }
    };

    // Act & Assert: call CreateOrderAsync and expect NotFoundException with specific message
    var ex = await Assert.ThrowsAsync<NotFoundException>(
        () => orderService.CreateOrderAsync(invalidProductDto)
    );

    // The exception message should specifically say Product with id 999 not found.
    Assert.Equal("Product with id 999 not found.", ex.Message);
}

Unit Test for Insufficient Stock

Attempts to order more items than are in stock. Expects an InvalidOperationException for not enough stock. Please add the following method to the OrderServiceUnitTests class. The following code is self-explained, so please read the comment lines for a better understanding.

[Fact]
public async Task CreateOrderAsync_InsufficientStock_ThrowsInvalidOperationException()
{
    // Arrange: get a fresh context + service
    var (dbContext, orderService) = BuildTestContextAndService();

    // Build a DTO requesting 10 units of Product 1 (stock is only 5)
    var insufficientStockDto = new OrderCreateDTO
    {
        CustomerId = 1,
        Items = new List<OrderItemDTO>
        {
            new() { ProductId = 1, Quantity = 10 }
        }
    };

    // Act & Assert: calling CreateOrderAsync should throw InvalidOperationException
    var ex = await Assert.ThrowsAsync<InvalidOperationException>(
        () => orderService.CreateOrderAsync(insufficientStockDto)
    );

    // The exception message should contain Not enough stock for product
    Assert.Contains("Not enough stock for product", ex.Message);
}

Unit Test for Fetching an Existing Order

Places a real order first. Then, fetches the order by ID and verifies that the order returned matches what was created. Please add the following method to the OrderServiceUnitTests class. The following code is self-explained, so please read the comment lines for a better understanding.

[Fact]
public async Task GetOrderByIdAsync_ExistingOrder_ReturnsOrderResponse()
{
    // Arrange: create a new context + service
    var (dbContext, orderService) = BuildTestContextAndService();

    // First, place an order so that it exists in the in-memory database.
    var createDto = new OrderCreateDTO
    {
        CustomerId = 1,
        Items = new List<OrderItemDTO>
        {
            new() { ProductId = 1, Quantity = 1 } // small order
        }
    };

    // Create the order and capture the returned OrderResponseDTO
    var createdOrder = await orderService.CreateOrderAsync(createDto);

   // Assert: the returned DTO is not null (order was created successfully)
    Assert.NotNull(createdOrder);

    // Extract the newly assigned OrderId (populated by the service & repository)
    var orderId = createdOrder.OrderId;

    // Act: fetch the same order by ID
    var fetchedOrder = await orderService.GetOrderByIdAsync(orderId);

    // Assert: fetchedOrder should not be null (order exists)
    Assert.NotNull(fetchedOrder);

    // Validate that fetchedOrder.OrderId == orderId
    Assert.Equal(orderId, fetchedOrder.OrderId);

    // Validate that fetchedOrder.CustomerId == 1 (as we created)
    Assert.Equal(1, fetchedOrder.CustomerId);

    // Because we ordered 1 item, OrderItems.Count should be 1
    Assert.Single(fetchedOrder.OrderItems);
}

Unit Test for Fetching a Non-Existent Order

Attempts to fetch an order ID that was never created. Should return null (not throw), showing the service correctly returns not found. Please add the following method to the OrderServiceUnitTests class. The following code is self-explained, so please read the comment lines for a better understanding.

[Fact]
public async Task GetOrderByIdAsync_OrderMissing_ReturnsNull()
{
    // Arrange: fresh context/service, no orders have ever been created
    var (dbContext, orderService) = BuildTestContextAndService();

    // Act: attempt to fetch an Order with ID = 999 (does not exist)
    var result = await orderService.GetOrderByIdAsync(999);

    // Assert: because no such Order exists, the service should return null (not throw)
    Assert.Null(result);
}

Drawbacks of the In-Memory Approach:

• Less isolation (also tests repository logic).
• Different behaviour vs production (e.g., relational constraints not enforced).
• Harder to simulate exceptions or edge cases.
• Potentially slower for large test suites.

What is Moq?

Moq is a popular, open‐source mocking framework for .NET. It generates fake objects (mocks) at runtime for any interface or virtual or abstract class. Moq is designed to be:

• Lightweight: Minimal setup overhead
• Fluent: You configure method behaviours with a chainable, expressive syntax
• Asynchronous support: Built‐in ReturnsAsync(…) for methods returning Task<T>
• Well‐Documented: Widely used in the .NET community, with plenty of examples and guidance

Example to Understand Unit Tests with Moq

Now, we will use Moq to create mocks for repository dependencies. So, create a class file named OrderServiceUnitTestsWithMoq.cs within the Services folder of ProductCatalog.Tests project, and then copy and paste the following code.

using Moq;                                                        
using ProductCatalog.API.DTOs;                  
using ProductCatalog.API.Exceptions;            
using ProductCatalog.API.Models;                
using ProductCatalog.API.Repositories;          
using ProductCatalog.API.Services;              
using Xunit;                                    
namespace ProductCatalog.Tests.Services
{
public class OrderServiceUnitTestsWithMoq
{
// Declare private fields for each mock repository interface:
private readonly Mock<IOrderRepository> _mockOrderRepo;
private readonly Mock<IProductRepository> _mockProductRepo;
private readonly Mock<ICustomerRepository> _mockCustomerRepo;
// Finally, we declare the IOrderService under test. We will pass mock.Object instances into it.
private readonly IOrderService _orderService;
// Constructor runs before every [Fact], setting up fresh mocks + service:
public OrderServiceUnitTestsWithMoq()
{
// Create mock instances for each repository interface:
_mockOrderRepo = new Mock<IOrderRepository>();
_mockProductRepo = new Mock<IProductRepository>();
_mockCustomerRepo = new Mock<ICustomerRepository>();
// Finally, create the OrderService under test, injecting the mocks’ .Object properties
//    - mockOrderRepo.Object is the actual fake IOrderRepository
//    - mockProductRepo.Object is the fake IProductRepository
//    - mockCustomerRepo.Object is the fake ICustomerRepository
_orderService = new OrderService(
_mockOrderRepo.Object,
_mockProductRepo.Object,
_mockCustomerRepo.Object);
}
// Unit Test for Successful Order Creation
[Fact]
public async Task CreateOrderAsync_WithValidInput_ReturnsOrderResponse()
{
// Define a valid customerId we will use for this test:
int customerId = 1;
// Build an OrderCreateDTO with two items:
//    - Item 1: ProductId=10, Quantity=2
//    - Item 2: ProductId=20, Quantity=1
var orderDto = new OrderCreateDTO
{
CustomerId = customerId,
Items = new List<OrderItemDTO>
{
new() { ProductId = 10, Quantity = 2 },
new() { ProductId = 20, Quantity = 1 }
}
};
// Setup the customer repository mock to return a valid Customer when GetByIdAsync(customerId) is called:
_mockCustomerRepo
.Setup(r => r.GetByIdAsync(customerId))
.ReturnsAsync(new Customer { Id = customerId, Name = "Test Customer" });
// Setup the product repository mock for ProductId=10:
//     - When GetByIdAsync(10) is called, return a Product with Stock=5, Price=50
_mockProductRepo
.Setup(r => r.GetByIdAsync(10))
.ReturnsAsync(new Product { Id = 10, Name = "Product10", Price = 50, Stock = 5 });
// Setup the product repository mock for ProductId=20 similarly:
_mockProductRepo
.Setup(r => r.GetByIdAsync(20))
.ReturnsAsync(new Product { Id = 20, Name = "Product20", Price = 100, Stock = 3 });
// Setup the order repository mock’s AddAsync to do nothing (complete the Task) but be marked Verifiable
// Whenever AddAsync is called with any Order object (doesn’t matter which one), just return a completed Task.
// In Verify, it checks "was this method called with any Order?"(regardless of the actual order details).
_mockOrderRepo
.Setup(r => r.AddAsync(It.IsAny<Order>())) 
.Returns(Task.CompletedTask)
.Verifiable(); // we will Verify() later that AddAsync was called once
// Act: Call the service’s CreateOrderAsync
var result = await _orderService.CreateOrderAsync(orderDto);
// Assert: The returned DTO should not be null (order was created successfully)
Assert.NotNull(result);
// Assert: The CustomerId in the result should equal the one we passed (1)
Assert.Equal(customerId, result.CustomerId);
// Assert: The service should return 2 order items (we passed two items)
Assert.Equal(2, result.OrderItems.Count);
// Verify that AddAsync(Order) was called exactly once on the mock order repository
_mockOrderRepo.Verify(r => r.AddAsync(It.IsAny<Order>()), Times.Once);
}
// Unit Test for Customer Not Found
[Fact]
public async Task CreateOrderAsync_CustomerNotFound_ThrowsNotFoundException()
{
// Setup CustomerRepository.GetByIdAsync(any int) to always return null (no such customer)
// This will return null regardless of what CustomerId you ask for.
// It's useful for "simulate not found" or "simulate error" cases.
_mockCustomerRepo
.Setup(r => r.GetByIdAsync(It.IsAny<int>())) 
.ReturnsAsync((Customer?)null);
// Build a DTO with CustomerId=999, which our mock will treat as Not Found
var orderDto = new OrderCreateDTO
{
CustomerId = 999,
Items = new List<OrderItemDTO> { new() { ProductId = 1, Quantity = 1 } }
};
// Act & Assert: calling CreateOrderAsync should immediately throw NotFoundException
await Assert.ThrowsAsync<NotFoundException>(() =>
_orderService.CreateOrderAsync(orderDto)
);
}
// Unit Test for Product Not Found
[Fact]
public async Task CreateOrderAsync_ProductNotFound_ThrowsNotFoundException()
{
// Define a valid customerId and have the customer mock return a real Customer
int customerId = 1;
_mockCustomerRepo
.Setup(r => r.GetByIdAsync(customerId))
.ReturnsAsync(new Customer { Id = customerId });
// Setup ProductRepository.GetByIdAsync(any int) to return null, simulating Product Not Found
_mockProductRepo
.Setup(r => r.GetByIdAsync(It.IsAny<int>()))
.ReturnsAsync((Product?)null);
// Create a DTO requesting ProductId=999 (our mock will indeed say NULL)
var orderDto = new OrderCreateDTO
{
CustomerId = customerId,
Items = new List<OrderItemDTO> { new() { ProductId = 999, Quantity = 1 } }
};
// Act & Assert: expecting NotFoundException because the service calls GetByIdAsync(999) → null
await Assert.ThrowsAsync<NotFoundException>(() =>
_orderService.CreateOrderAsync(orderDto)
);
}
// Unit Test for Insufficient Stock
[Fact]
public async Task CreateOrderAsync_InsufficientStock_ThrowsInvalidOperationException()
{
// Define a valid customerId and return a real Customer from the mock
int customerId = 1;
_mockCustomerRepo
.Setup(r => r.GetByIdAsync(customerId))
.ReturnsAsync(new Customer { Id = customerId });
// Setup ProductRepository.GetByIdAsync(10) to return a Product with only Stock=1
_mockProductRepo
.Setup(r => r.GetByIdAsync(10))
.ReturnsAsync(new Product { Id = 10, Stock = 1 });
// Build a DTO requesting Quantity=5 of ProductId=10 (only 1 in stock)
var orderDto = new OrderCreateDTO
{
CustomerId = customerId,
Items = new List<OrderItemDTO> { new() { ProductId = 10, Quantity = 5 } }
};
// Act & Assert: the service should throw InvalidOperationException because 5 > stock(1)
await Assert.ThrowsAsync<InvalidOperationException>(() =>
_orderService.CreateOrderAsync(orderDto)
);
}
// Unit Test for Fetching an Existing Order 
[Fact]
public async Task GetOrderByIdAsync_ExistingOrder_ReturnsOrderResponse()
{
// We define an orderId and construct an Order entity (as if it were already in the DB)
int orderId = 100;
var order = new Order
{
Id = orderId,
CustomerId = 1,
BaseAmount = 150,
DiscountAmount = 0,
TotalAmount = 150,
OrderItems = new List<OrderItem>
{
new OrderItem { ProductId = 10, Quantity = 3, UnitPrice = 50, LineTotal = 150 }
}
};
// Setup the order repository mock to return that Order whenever GetByIdAsync(orderId) is called
_mockOrderRepo
.Setup(r => r.GetByIdAsync(orderId))
.ReturnsAsync(order);
// Act: call the service’s GetOrderByIdAsync(orderId)
var result = await _orderService.GetOrderByIdAsync(orderId);
// Assert: the returned OrderResponseDTO should not be null
Assert.NotNull(result);
// Assert: the returned DTO’s OrderId should match the one we passed in
Assert.Equal(orderId, result.OrderId);
// Assert: the returned DTO’s CustomerId should be 1
Assert.Equal(1, result.CustomerId);
// Assert: Because the Order had exactly one OrderItem, the DTO should have one item
Assert.Single(result.OrderItems);
}
//Unit Test for Fetching a Non-Existent Order 
[Fact]
public async Task GetOrderByIdAsync_OrderMissing_ReturnsNull()
{
// Arrange: pick an orderId that does not exist (e.g., 999).
int missingOrderId = 999;
// Configure the IOrderRepository mock to return null whenever GetByIdAsync is called
//    with any integer (including 999). This simulates Order Not Found in the database.
_mockOrderRepo
.Setup(r => r.GetByIdAsync(It.IsAny<int>()))
.ReturnsAsync((Order?)null);
// Act: call the service’s GetOrderByIdAsync method with the missingOrderId.
//    Because of our setup, the mock will return null, and the service should propagate that.
var result = await _orderService.GetOrderByIdAsync(missingOrderId);
// Assert: since no order exists, the service should return null rather than throwing.
Assert.Null(result);
// (Optional) Verify that the repository’s GetByIdAsync was indeed called exactly once
//    with the missingOrderId. This ensures the service tried to fetch the order.
_mockOrderRepo.Verify(r => r.GetByIdAsync(missingOrderId), Times.Once);
}
}
}

Unit testing the Service Layer is essential for robust, refactorable business logic. Mocking repositories either via EF InMemory (realistic, but less isolated) or via Moq (pure isolation) is key. Write tests for all scenarios: success, not found, error cases.

In the next article, I will discuss Unit Testing the Controllers of our ASP.NET Core Web API Project. In this article, I explain Unit Testing the Service Layer of our ASP.NET Core Web API. I hope you enjoy this article on Unit Testing the Service Layer of our ASP.NET Core Web API.