.NET Patterns: Builder, Exceptions & CLI Setup

Key Takeaways

Fluent Builder improves test readability by chaining method calls instead of constructor telescoping. Custom Exceptions carry HTTP status codes and centralized error codes for API consistency. Proper project structure (src/tests separation) scales with dotnet CLI best practices.

Fluent Builder Pattern for Unit Tests

The classic constructor approach becomes unreadable with many parameters. A User object with 5+ properties forces you to count arguments, guess order, and maintain brittle tests.

The Fluent Builder reads like English:

var user = new UserBuilder()
    .WithName("John Doe")
    .WithEmail("john.doe@example.com")
    .WithAge(30)
    .Build();

Each method returns this, enabling method chaining. Your test intent becomes crystal clear—no squinting at constructor arguments.

Classic vs. Fluent Comparison

Aspect	Classic Constructor	Fluent Builder
Readability	new User("John Doe", "john@...", 30, "Admin")	Chained readable calls
Parameter Order	Easy to mess up	Self-documenting
Test Maintenance	Breaks when signature changes	Flexible, optional params
Complex Objects	Constructor telescoping chaos	Graceful, modular

Builder Implementation

public class UserBuilder
{
    private string _name = "Guest";
    private string _email = "guest@example.com";
    private int _age = 18;

    public UserBuilder WithName(string name)
    {
        _name = name;
        return this;
    }

    public UserBuilder WithEmail(string email)
    {
        _email = email;
        return this;
    }

    public UserBuilder WithAge(int age)
    {
        _age = age;
        return this;
    }

    public User Build() => new User(_name, _email, _age);
}

Interview Angle

Q: When would you use Builder Pattern in your tests? A: For complex objects with multiple dependencies, optional fields, or when you’re testing variations of the same entity. It makes test intent obvious—readers see exactly what differs between test cases without parsing constructor noise.

Custom Exceptions

Native Exception is too generic. Your API handler can’t distinguish a 404 from a 500, and logs become noise. Custom exceptions carry HTTP status codes and error codes.

Three Exception Patterns

1. Abstract Base Class — Clear inheritance, centralized logic:

public abstract class CustomExceptionBase : Exception
{
    public string CustomMessage { get; }
    public HttpStatusCode StatusCode { get; }
    public string ErrorCode { get; }

    protected CustomExceptionBase(string message, string errorCode,
        HttpStatusCode statusCode)
    {
        CustomMessage = message;
        ErrorCode = errorCode;
        StatusCode = statusCode;
    }
}

2. Const Strings for Error Codes — Centralized, reusable:

public static class ErrorCodes
{
    public const string NotFound = "NOT_FOUND";
    public const string Unauthorized = "UNAUTHORIZED";
    public const string Conflict = "CONFLICT";
}

3. Specific Exception Types — Type-safe handling:

public class NotFoundException : CustomExceptionBase
{
    public NotFoundException(string message)
        : base(message, ErrorCodes.NotFound, HttpStatusCode.NotFound) { }
}

public class UnauthorizedException : CustomExceptionBase
{
    public UnauthorizedException(string message)
        : base(message, ErrorCodes.Unauthorized, HttpStatusCode.Unauthorized) { }
}

Exception Patterns Comparison

Pattern	Pros	Cons
Abstract Base	DRY, enforces structure	Requires all exceptions inherit
Generics (T)	Type-safe, flexible	More complex syntax
Const Strings	Reusable error codes	Need manual mapping

Interview Angle

Q: Why custom exceptions instead of throwing base Exception? A: Base Exception loses context. Custom exceptions carry HTTP status codes (404, 401, 500), error codes (“NOT_FOUND”), and custom fields. Your middleware catches specific types and responds appropriately. It’s the difference between “something broke” and “resource not found—return 404.”

Common Gotchas

Silently swallowing exceptions — Never catch (Exception) { } without logging or re-throwing. Using base Exception — Catch specific types so your middleware can handle 404 vs. 401 differently. Inconsistent error codes — Define codes once in ErrorCodes.cs, never hardcode strings.

.NET Project Structure with CLI

Professional projects separate source and tests for clarity. dotnet CLI automates this setup.

Starting Fresh

# Create Aspire starter template with Redis
dotnet new aspire-starter --use-redis-cache --output AspireSample

cd AspireSample

# Create directory structure
mkdir src tests

# Move projects into organized folders
mv ExpenseTracker.ApiService src/
mv ExpenseTracker.Tests tests/

# Recreate solution (new structure)
rm AspireSample.sln
dotnet new sln -n AspireSample

# Register projects to solution
dotnet sln AspireSample.sln add src/ExpenseTracker.ApiService/ExpenseTracker.ApiService.csproj
dotnet sln AspireSample.sln add tests/ExpenseTracker.Tests/ExpenseTracker.Tests.csproj

# Build and verify
dotnet restore && dotnet build

Directory Layout

AspireSample/
├── src/
│   ├── ExpenseTracker.ApiService/
│   │   └── ExpenseTracker.ApiService.csproj
│   └── ExpenseTracker.Shared/
├── tests/
│   └── ExpenseTracker.Tests/
│       └── ExpenseTracker.Tests.csproj
└── AspireSample.sln

Interview Angle

Q: Why separate src/ and tests/ directories? A: Clarity. Developers immediately know which projects are production vs. test. CI/CD pipelines can target folders (exclude tests from release builds). When you have 10+ projects, src/ and tests/ keep things scannable. Q: Why recreate the .sln after moving projects? A: dotnet solution references use absolute/relative paths. Moving projects invalidates old references. Recreating ensures all paths point to the new locations.

---

Next steps: Implement Fluent Builders in your test utilities, define custom exceptions in a shared layer, then scaffold your project with dotnet new to enforce structure from day one.