Dependency Injection, SOLID and Unit Testing in C#

Even for freshers, interviewers ask whether you can write code that is easy to change and easy to test. Dependency injection, SOLID and unit testing are how that is judged.

Dependency injection (DI)

A class has a dependency when it needs another object to do its job. Without DI, the class creates it itself (new EmailSender()), which glues the two together: you cannot swap the sender or test the class alone. With dependency injection, the dependency is given to the class from outside, usually through the constructor, and the class depends on an interface.

INotifier notifier = new EmailNotifier();
var service = new OrderService(notifier);
service.Place("A-100");                    // Email sent for A-100

public interface INotifier
{
    void Send(string message);
}

public class EmailNotifier : INotifier
{
    public void Send(string message) => Console.WriteLine($"Email sent for {message}");
}

public class OrderService(INotifier notifier)       // primary constructor (C# 12)
{
    public void Place(string orderId) => notifier.Send(orderId);
}

OrderService knows only the INotifier contract. In a test you pass a fake notifier. In production, you pass a real one. The principle behind this is inversion of control: the caller decides which implementation is used.

In ASP.NET Core, a built-in container creates and injects objects for you. You register services once:

builder.Services.AddTransient<IEmailBuilder, EmailBuilder>();
builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddSingleton<IClock, SystemClock>();

Service lifetimes

A common bug is the captive dependency: a singleton that depends on a scoped service keeps that one scoped instance forever. A service should never depend on one with a shorter lifetime.

SOLID in plain words

A tiny Open/Closed example: add a new discount rule by adding a class, not by editing existing code.

Unit testing

A unit test checks one small piece of behaviour in isolation, quickly and repeatably. In .NET the common frameworks are xUnit (the usual choice for new projects), NUnit and MSTest. Structure every test as Arrange, Act, Assert (AAA):

Good unit tests are:

• Fast and isolated: no database, no network, no real files. Use fakes or mocks for dependencies.
• Deterministic: no dependence on the clock, random numbers or the machine. Inject an instead of calling .
• Focused: one reason to fail, with a name that says what it checks ().

Testable code and DI go together: because takes an , you can test it without sending any email. See the xUnit test snippet.

Practise

1. Take a class that calls on its collaborators and refactor it to constructor injection with an interface.
2. Write two xUnit tests for : a normal case and a 0 percent case.
3. Explain "captive dependency" in two sentences.