Testable Code Through Dependency Injection

Writing code that’s easy to test is a big deal. It saves you time, prevents bugs from reaching users, and generally makes you a happier developer. One of the simplest, yet most powerful, techniques for achieving this is Dependency Injection.

What’s the Big Idea?

At its core, Dependency Injection is a design pattern. It means that instead of a class creating its own dependencies (other objects or services it needs to do its job), those dependencies are “injected” from the outside. Think of it like this: if your class needs a logger, it shouldn’t create the logger itself. Instead, you pass a logger into the class when you create it.

Why is this helpful for testing? Because in your tests, you can inject mock or fake versions of these dependencies. This lets you isolate the code you’re actually testing without worrying about the real dependencies.

A Simple Example (Without DI)

Let’s say we have a UserService that needs to save user data to a database. Without DI, it might look something like this:

1
class DatabaseService {
2
  save(data) {
3
    console.log("Saving to real database:", data);
4
    // Actual database save logic here...
5
  }
6
}
7

8
class UserService {
9
  constructor() {
10
    this.dbService = new DatabaseService(); // Creating its own dependency
11
  }
12

13
  createUser(userData) {
14
    // ... some logic ...
15
    this.dbService.save(userData);
16
    // ... more logic ...
17
  }
18
}
19

20
// Usage
21
const userService = new UserService();
22
userService.createUser({ name: "Alice" });

Now, imagine trying to write a unit test for UserService.createUser. If you run this code, this.dbService.save() will actually try to interact with a real database. That’s slow, messy, and unpredictable. You can’t easily check if save was called or what data was passed to it without setting up a whole database environment.

Introducing Dependency Injection

Let’s refactor this using DI. We’ll pass the DatabaseService (or whatever service handles data persistence) into the UserService constructor.

1
class DatabaseService {
2
  save(data) {
3
    console.log("Saving to real database:", data);
4
    // Actual database save logic here...
5
  }
6
}
7

8
class UserService {
9
  constructor(dbService) { // Dependency is injected
10
    this.dbService = dbService;
11
  }
12

13
  createUser(userData) {
14
    // ... some logic ...
15
    this.dbService.save(userData);
16
    // ... more logic ...
17
  }
18
}
19

20
// Real world usage
21
const realDbService = new DatabaseService();
22
const realUserService = new UserService(realDbService);
23
realUserService.createUser({ name: "Bob" });

Testing with Dependency Injection

This is where the magic happens. For our tests, we can create a “mock” or “stub” version of DatabaseService. This mock object will have a save method, but instead of talking to a real database, it will just record that it was called.

1
// Mock Database Service for testing
2
class MockDatabaseService {
3
  constructor() {
4
    this.savedData = null;
5
    this.saveCallCount = 0;
6
  }
7

8
  save(data) {
9
    this.savedData = data;
10
    this.saveCallCount++;
11
    console.log("Mock DB: save called with", data);
12
  }
13
}
14

15
// --- Inside our test file ---
16

17
// Setup
18
const mockDbService = new MockDatabaseService();
19
const testUserService = new UserService(mockDbService); // Injecting the mock!
20
const testUserData = { name: "Charlie" };
21

22
// Execute
23
testUserService.createUser(testUserData);
24

25
// Assertions
26
console.assert(mockDbService.saveCallCount === 1, "save should be called once");
27
assert.deepStrictEqual(mockDbService.savedData, testUserData, "Correct data should be saved");
28
console.log("Test passed!");

See how clean that is? The test for UserService.createUser is now focused purely on the UserService logic. It doesn’t care how the DatabaseService saves data; it only cares that it was called with the correct data. This makes tests faster, more reliable, and easier to understand.

Benefits Beyond Testing

While testing is a primary motivator, DI offers other advantages:

Decoupling: Your classes aren’t tightly bound to specific implementations of their dependencies.
Flexibility: It’s easier to swap out dependencies. Need to change your database? Just inject a new implementation.
Readability: The constructor clearly shows what a class needs to function.

Getting Started

Many modern frameworks and languages have built-in support or popular libraries for dependency injection. Even without a formal framework, manually injecting dependencies as shown above is straightforward and highly effective. Start by looking at your classes that create new instances of other objects. Ask yourself: “Could this dependency be injected instead?” The answer is almost always yes, and your test suite will thank you.

Tags: Software Development, Testing, Dependency Injection, Clean Code