Title: Our Renewal Reminders Went to Expired Customers, and We Couldn’t Test It

The task sounded simple: email customers 3 days before their subscription expires.

A few weeks after launch, support forwarded us angry messages. Customers whose subscriptions had already expired were getting “renew soon” emails every single day.

The bug was one missing condition. What hurt more was the reason we missed it: the code was impossible to unit test.

What Dependency Inversion really means

The Dependency Inversion Principle says that high-level business logic should not depend on low-level details like databases, email servers, or the system clock. Both should depend on abstractions, which are usually interfaces.

Here is the code we shipped:

public class RenewalReminderService
{
    public void SendReminders()
    {
        var repository = new SqlSubscriptionRepository();
        var smtp = new SmtpClient("smtp.company.com");

        var expiring = repository.GetAll()
            .Where(s => (s.ExpiresOn - DateTime.Now).TotalDays <= 3);

        foreach (var subscription in expiring)
        {
            smtp.Send("no-reply@company.com", subscription.Email,
                "Renew soon", "Your plan expires soon.");
        }
    }
}

Look at the condition. If a subscription expired two weeks ago, the difference is negative, and a negative number is always less than or equal to 3. Expired customers were included.

Why nobody caught it

To test this method, you would need:

• A real SQL database with test data
• A real SMTP server, or you’d email real people
• A way to control what DateTime.Now returns, which is impossible

So nobody wrote a test. The high-level rule, “who gets a reminder,” was welded to three low-level details.

The fix: depend on abstractions

First we define what the business logic needs, next to the business logic:

public interface ISubscriptionRepository
{
    Task<IReadOnlyList<Subscription>> GetActiveAsync(CancellationToken ct);
}

public interface IEmailSender
{
    Task SendAsync(string to, string subject, string body, CancellationToken ct);
}

For time, .NET 8 and later has TimeProvider built in, so we don’t need to invent our own clock interface. Now the service:

public class RenewalReminderService
{
    private readonly ISubscriptionRepository _subscriptions;
    private readonly IEmailSender _email;
    private readonly TimeProvider _time;

    public RenewalReminderService(
        ISubscriptionRepository subscriptions,
        IEmailSender email,
        TimeProvider time)
    {
        _subscriptions = subscriptions;
        _email = email;
        _time = time;
    }

    public async Task SendRemindersAsync(CancellationToken ct)
    {
        var now = _time.GetUtcNow();
        var subscriptions = await _subscriptions.GetActiveAsync(ct);

        foreach (var s in subscriptions)
        {
            var daysLeft = (s.ExpiresOn - now).TotalDays;

            if (daysLeft is >= 0 and <= 3)
                await _email.SendAsync(s.Email, "Renew soon", "Your plan expires soon.", ct);
        }
    }
}

Now the rule is clear and readable, and the missing lower bound (>= 0) is obvious.

The test we couldn’t write before

[Fact]
public async Task Does_not_remind_expired_subscribers()
{
    var time = new FakeTimeProvider(new DateTimeOffset(2026, 10, 13, 0, 0, 0, TimeSpan.Zero));
    var repository = new FakeSubscriptionRepository(
        new Subscription { Email = "a@x.com", ExpiresOn = time.GetUtcNow().AddDays(-1) });
    var email = new FakeEmailSender();
    var service = new RenewalReminderService(repository, email, time);

    await service.SendRemindersAsync(CancellationToken.None);

    Assert.Empty(email.Sent);
}

No database, no mail server, and the clock is under our control. FakeTimeProvider comes from the Microsoft.Extensions.TimeProvider.Testing package.

Wiring it up

In production, the real implementations are plugged in at startup:

builder.Services.AddSingleton(TimeProvider.System);
builder.Services.AddScoped<ISubscriptionRepository, SqlSubscriptionRepository>();
builder.Services.AddScoped<IEmailSender, SmtpEmailSender>();
builder.Services.AddScoped<RenewalReminderService>();

Where the interfaces live matters

ISubscriptionRepository and IEmailSender belong with the business logic, not with the SQL or SMTP code. SqlSubscriptionRepository and SmtpEmailSender depend on those interfaces, not the other way around. That is the “inversion”: the details now point toward the business rules.

Three terms people mix up

• Dependency Inversion is the principle: depend on abstractions
• Dependency Injection is the technique: pass dependencies in through the constructor
• The IoC container is the tool that does the passing for you

When not to do this

You don’t need an interface for every class. Invert dependencies at the boundaries: databases, network calls, the file system, the clock, and randomness. A small helper that formats a string doesn’t need one.

The lesson

If you can’t write a fast unit test for your most important logic, it’s usually because it creates its own dependencies. Make the business rule depend on interfaces, inject the details from outside, and the code becomes testable and replaceable at the same time.

Title: We Needed a Read-Only Repository. The Interface Forced Us to Fake Seven Methods.

Our reporting queries were slowing down the main database. The fix was clear: send report queries to a read replica.

So I created ReadReplicaUserRepository. Then I opened the interface it had to implement and my heart sank. IUserRepository had seven methods, and five of them were about writing data.

A read-only database was being forced to implement Add, Update, Delete, and BulkImport.

What Interface Segregation really means

The Interface Segregation Principle says that no class should be forced to depend on methods it doesn’t use. In practice, it means: don’t build one big interface that serves everybody. Build smaller ones shaped around what each client actually needs.

Here is the interface we had:

public interface IUserRepository
{
    User? GetById(int id);
    IReadOnlyList<User> GetAll();
    void Add(User user);
    void Update(User user);
    void Delete(int id);
    void BulkImport(IEnumerable<User> users);
    string ExportToCsv();
}

And the report service that used it:

public class UserReportService
{
    private readonly IUserRepository _users;

    public UserReportService(IUserRepository users) => _users = users;

    public int CountActiveUsers()
        => _users.GetAll().Count(u => u.IsActive);
}

UserReportService reads one method. But it depends on all seven. That causes real problems:

• The read replica class has to implement write methods it can’t support, usually by throwing exceptions
• Hand-written test fakes must implement all seven methods just to test one
• A change to BulkImport can force recompiling and retesting code that only reads

The fix: split by who uses it

public interface IUserReader
{
    User? GetById(int id);
    IReadOnlyList<User> GetAll();
}

public interface IUserWriter
{
    void Add(User user);
    void Update(User user);
    void Delete(int id);
}

public interface IUserImporter
{
    void BulkImport(IEnumerable<User> users);
}

ExportToCsv didn’t belong in a repository at all, so it moved to a CsvUserExporter class. That was a separate responsibility hiding inside the interface.

The main database class can still implement everything:

public class SqlUserRepository : IUserReader, IUserWriter, IUserImporter
{
    // all methods
}

And the read replica now only promises what it can really do:

public class ReadReplicaUserRepository : IUserReader
{
    public User? GetById(int id) { /* query the replica */ }
    public IReadOnlyList<User> GetAll() { /* query the replica */ }
}

The report service asks only for what it needs:

public class UserReportService
{
    private readonly IUserReader _users;

    public UserReportService(IUserReader users) => _users = users;

    public int CountActiveUsers()
        => _users.GetAll().Count(u => u.IsActive);
}

Wiring it up

This is where the payoff shows. Reports read from the replica, while writes go to the primary:

builder.Services.AddScoped<SqlUserRepository>();
builder.Services.AddScoped<IUserWriter>(sp => sp.GetRequiredService<SqlUserRepository>());
builder.Services.AddScoped<IUserImporter>(sp => sp.GetRequiredService<SqlUserRepository>());
builder.Services.AddScoped<IUserReader, ReadReplicaUserRepository>();

The first line registers the SQL class itself, and the next two lines forward the interfaces to that same instance. That way you get one SqlUserRepository per request, not one per interface.

Testing gets easier too

public class FakeUserReader : IUserReader
{
    private readonly List<User> _users;
    public FakeUserReader(params User[] users) => _users = users.ToList();

    public User? GetById(int id) => _users.FirstOrDefault(u => u.Id == id);
    public IReadOnlyList<User> GetAll() => _users;
}

Two methods instead of seven. The test says exactly what the report service needs, and nothing else.

When not to overdo it

Don’t split into one-method interfaces by reflex. Group methods by the client that uses them. Two or three well-chosen role interfaces beat fifteen tiny ones.

The lesson

A fat interface couples unrelated clients together and forces implementers to lie. Shape interfaces around what the caller needs, and you also get honest implementations and simpler tests.

Title: Support Clicked “Refund.” The Server Threw an Exception.

We added gift cards as a payment method. Quick job: create a GiftCardPayment class, inherit from our PaymentMethod base class, done.

Two weeks later, a support agent clicked Refund on an order paid with a gift card, and the page returned a 500 error.

The code compiled. The tests passed. It still crashed in production, because the subclass didn’t keep the promises its parent made.

What Liskov Substitution really means

The Liskov Substitution Principle says that a subclass must be usable anywhere its base class is used, without the program breaking or behaving strangely.

Think of inheritance as a promise. The base class tells every caller, “anything of this type can do these things.” If a subclass can’t keep that promise, every caller that trusted it is now in danger.

Here is what we wrote:

public abstract class PaymentMethod
{
    public abstract void Charge(decimal amount);
    public abstract void Refund(decimal amount);
}

public class CreditCardPayment : PaymentMethod
{
    public override void Charge(decimal amount) { /* charge the card */ }
    public override void Refund(decimal amount) { /* refund to the card */ }
}

public class GiftCardPayment : PaymentMethod
{
    public override void Charge(decimal amount) { /* deduct from balance */ }

    public override void Refund(decimal amount)
        => throw new NotSupportedException("Gift cards cannot be refunded.");
}

And the code that used it:

public class RefundService
{
    public void RefundOrder(Order order)
    {
        order.PaymentMethod.Refund(order.Total); // crashes for gift cards
    }
}

RefundService did nothing wrong. It trusted that any PaymentMethod can refund, because the base class said so. The gift card class broke that promise.

How to spot a Liskov violation

• An override that throws NotImplementedException or NotSupportedException
• An override that silently does nothing
• Callers that check “is” or “as” before using a method, because they don’t trust the type
• A subclass that rejects inputs the base class accepts

Fix 1: make the contract something every type can honor

Ask what the business actually wants. For us, refunding a gift card payment means giving the customer store credit. That is valid behavior, so we can make the contract say so:

public enum RefundOutcome
{
    RefundedToOriginalMethod,
    StoreCreditIssued
}

public abstract class PaymentMethod
{
    public abstract void Charge(decimal amount);
    public abstract RefundOutcome Refund(decimal amount);
}

public class GiftCardPayment : PaymentMethod
{
    public override void Charge(decimal amount) { /* deduct from balance */ }

    public override RefundOutcome Refund(decimal amount)
    {
        // add the amount back as store credit
        return RefundOutcome.StoreCreditIssued;
    }
}

Now RefundService works for every payment type, and the UI can show a different message depending on the outcome.

Fix 2: if a type truly can’t do it, don’t give it the method

Sometimes there is no sensible behavior. Then the operation shouldn’t be on the shared type at all:

public interface IPaymentMethod
{
    void Charge(decimal amount);
}

public interface IRefundablePayment : IPaymentMethod
{
    void Refund(decimal amount);
}

public class CreditCardPayment : IRefundablePayment { /* ... */ }
public class GiftCardPayment : IPaymentMethod { /* Charge only */ }

A method that needs refunds now asks for an IRefundablePayment. The compiler stops anyone from passing a gift card to it, so the mistake becomes a build error and not a production error.

The lesson

“Is-a” in code means “behaves-as,” not “sounds like it in English.” A Square inheriting from Rectangle sounds right, until someone sets width and height separately. Before you inherit, ask one question: can every caller of the base type safely use my subclass without knowing which one they got? If the honest answer is no, the design needs to change, not the caller.