Interfaces

An interface is a list of members a type promises to provide, with no code behind any of them. It says what can be done and stays silent on how.

That sounds thin, and the value is not obvious until you see what it lets you replace. The payoff this lesson is aiming at is concrete: being able to test the logic that marks an invoice as paid without a database anywhere near it.

By convention C# interface names begin with a capital I. It is only a convention, and it is followed near-universally.

public interface IInvoiceStore
{
    Invoice? FindByReference(string reference);
    void Save(Invoice invoice);
}

public class SqlInvoiceStore : IInvoiceStore
{
    // Talks to the real database. Omitted here; the point is that it exists.
    public Invoice? FindByReference(string reference) => throw new NotImplementedException();
    public void Save(Invoice invoice) => throw new NotImplementedException();
}

public class InvoiceService
{
    private readonly IInvoiceStore _store;

    // The service is handed what it needs instead of creating it.
    public InvoiceService(IInvoiceStore store)
    {
        _store = store;
    }

    public void MarkPaid(string reference, DateOnly paidOn)
    {
        Invoice? invoice = _store.FindByReference(reference);

        if (invoice is null)
        {
            throw new InvalidOperationException($"No invoice found with reference {reference}.");
        }

        invoice.MarkPaid(paidOn);
        _store.Save(invoice);
    }
}

• Interface members have no bodies and no access modifiers. They are public by definition — an interface is entirely a public contract.
• public class SqlInvoiceStore : IInvoiceStore means this class implements the contract. If it misses a member, it does not compile.
• The question mark in Invoice? says the method may return nothing. Nullable reference types get their own lesson later; for now read it as "this might be null, so check it".
• InvoiceService holds IInvoiceStore, not SqlInvoiceStore. It has no idea whether storage is a database, a file or a list in memory, and cannot find out.
• The constructor receiving the store rather than writing new SqlInvoiceStore() inside is the whole trick. A class that receives what it needs instead of creating it is said to use dependency injection — the term is grander than the idea.

Now consider testing MarkPaid. There are three behaviours worth checking: a known reference gets marked paid and saved, an unknown reference throws, and an already-paid invoice is handled however you decided it should be.

If InvoiceService created its own SqlInvoiceStore, every one of those tests needs a database. You would need a server running, a schema, seed rows in a known state, and cleanup afterwards so the next test is not affected by this one. The tests would take seconds each, would fail on a laptop with no database, and would fail for reasons that have nothing to do with MarkPaid.

Because the service depends on an interface, you can hand it a different implementation.

public class InMemoryInvoiceStore : IInvoiceStore
{
    private readonly List<Invoice> _invoices;

    public int SaveCount { get; private set; }

    public InMemoryInvoiceStore(List<Invoice> seed)
    {
        _invoices = new List<Invoice>(seed);
    }

    public Invoice? FindByReference(string reference)
    {
        foreach (Invoice invoice in _invoices)
        {
            if (invoice.Reference == reference)
            {
                return invoice;
            }
        }

        return null;
    }

    public void Save(Invoice invoice)
    {
        SaveCount++;

        if (!_invoices.Contains(invoice))
        {
            _invoices.Add(invoice);
        }
    }
}

// In a test: no database, no configuration, no cleanup.
Invoice invoice = new Invoice("INV-2201", 15_000m);
InMemoryInvoiceStore store = new InMemoryInvoiceStore(new List<Invoice> { invoice });
InvoiceService service = new InvoiceService(store);

service.MarkPaid("INV-2201", new DateOnly(2026, 3, 14));

Console.WriteLine(invoice.IsPaid);    // True
Console.WriteLine(store.SaveCount);   // 1

• This class satisfies the same contract with a list instead of a database. InvoiceService cannot tell the difference, because the interface is all it ever sees.
• new List<Invoice>(seed) copies the items into a new list, so the caller's list is not modified by later Save calls.
• SaveCount is not part of IInvoiceStore. It exists so a test can check that the service actually saved, which is behaviour worth asserting and would otherwise be invisible.
• The test runs in well under a millisecond, needs nothing installed, and fails only if MarkPaid is wrong. Those three properties are what make a test suite worth keeping.
• A stand-in like this is usually called a fake. Mocking libraries generate similar objects for you, and hand-written fakes remain a perfectly good option, particularly for interfaces you use in many tests.