DEV Community: Thiago Luiz Silva

A gentle introduction to dependency injection

Thiago Luiz Silva — Wed, 25 Aug 2021 18:00:00 +0000

Objective

To test applications, We need to ensure that their parts don’t depend on each other, and this principle is the key to it.

The objective here is to quickly explain dependency injection and how it can help test without diving too deep into its implementation in programming languages or frameworks.

What is Dependency Injection:

Wikipedia summarizes Dependency Injection as:

(…) the dependency inversion principle is a specific form of loosely coupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details

We have a lot of complicated words here: what is dependency? Coupling? Injecting? is this a vaccine?

We refer to a dependency as something that your object needs to work. For example, A surgeon may require a scalpel, so this is a dependency to do a surgery. When the medic asks for a scalpel, bistoury, or lint and the auxiliary passes it to him/her, the auxiliary injects the needed dependencies to make a surgery.

Other real-life analogies:

If you want to cut something, you’ll need something that can cut (Cut method in ISharp interface). It can be a knife, a scalpel, a sword, a chainsaw…
If you want to go to point A to B in your city, you may ask for a Uber; it doesn’t matter who is your driver or the car;

I like to summarize it as the ” Hollywood principle: Don’t call us, We call You!” (I don’t know who coined this, but I’ve traced it back to a post from Stefano Mazzocchi).

The code example

Lets think we have a Samurai and a Sword in our Game:

class Samurai {  
  constructor() {
    this.weapon = new Sword();
  }

  hit(enemy) {
    this.weapon.hit(enemy);    
  }
}

class Sword : Weapon {
  hit(enemy) {
    // (...)
  }  
}

class Game {
  constructor() {
    this.samurai = new Samurai();
  }
}

This Samurai is coupled with the Sword object; he can’t use other weapons! Let’s apply some Dependency Inversion:

class Samurai {  
  constructor(weapon) {
    this.weapon = weapon;
  }

  hit(enemy) {
    this.weapon.hit(enemy);    
  }
}

class Sword : Weapon {
  hit(enemy) {
    // (...)
  }  
}

class Game {
  constructor() {
    this.samurai = new Samurai(new Sword());
  }
}

Now the Samurai can use anything that is a weapon, and we can write tests for it without depending on the Sword object:

class TestSword : Weapon {
  hit(enemy) {
    // (...) we can spy the enemy to ensure it's been hit 😜
  }  
}

class Test {
  constructor() {
    this.samurai = new Samurai(new TestSword());
  }
}

Things can become quite complicated when dealing with multiple dependencies, that’s when We can introduce a Dependency Injection framework. The general idea is to register the types and let the framework do the hard work, something like:

class Test {
  constructor() {
    /* General idea of something to control dependencies*/
    this.di = new DependencyInjectionContainer();
    di.Register(Samurai);
    di.Register(TestSword);

    /* Here the magic happens:
     The DI container resolve its classes to concrete types.
     All dependency injection frameworks will do this somehow*/
    di.ResolveDependencies();

    this.samurai = this.di.Get(Samurai);
  }
}

Summary

This is just a high-level view of Dependency Injection (DI), and We’ll go back to it from time to time when implementing tests.

Going deeper into Domain-Driven Design (DDD), this principle allows us to write our Domains and Repositories without dependencies in external components. As a result, we can focus our tests on the algorithm instead of building things.

As usual, DI is not a silver bullet: You should know when to use it. Things can go out of control, and your code doesn’t have anything concrete; everything is injected from some obscure configuration somewhere (yes, I’m looking at You Java/Spring). We’ll try to find the right balance between abstractions and concrete types as we go.

To summarize: Don’t let your classes build dependencies; let other high-level components handle that for them.

Sources

Wikipedia https://en.wikipedia.org/wiki/Dependency_inversion_principle
Martin Fowler excellent article about DI: https://martinfowler.com/articles/injection.html

Spying (on) Methods with Jest

Thiago Luiz Silva — Sat, 21 Aug 2021 09:00:00 +0000

How mocks make it easy to ensure your application logic

It’s easy to test your application when your domain layer is decoupled from other:

For example, let’s imagine the following scenario:

In a Race Game, when the Car hit an obstacle, the player will go back a couple of yards, and the barrier will be removed

The Pseudo-code

We have a Game class that receives the Player and the ObstacleManager:

public class Game {

  public Game(Player player, ObstacleManager obstacleManager) { 
    (...) /* Setup game, objects, etc */
  }

  public class updateGameState() {
    const collision = player.checkCollision(obstacleManager);

    if(collision) {
      obstacleManager.Remove(collision.Obstacle);
      player.Knockback();
    }
  }
}

The Test - the slow way:

The direct (aka: “slow”) approach is to instantiate the objects directly

describe("Game Tests", () => {
  test("The player should hit obstacle in same position", () => {
    const obstacle = new Obstacle(0,0); /*creating objects with the position*/
    const obstacleManager = new ObstacleManager([obstacle]);
    const player = new Player(0, 0);

    const collision = player.checkCollision(obstacleManager);

    expect(collision).toBe(obstacle);
  });

  test("The player should have a Knockback if hit an obstacle", () => {
    const obstacle = new Obstacle(0,0); /*creating objects with the position*/
    const obstacleManager = new ObstacleManager([obstacle]);
    const player = new Player(0, 0);

    const game = new Game(player, obstacleManager);    
    game.updateGameState();

    expect(player.Knockbacked).toBe(true);
  });
});

This kind of approach is still valid (it’s better to have some tests than no test at all), but it has some issues:

Your tests may become brittle over time - Every change to the entities (player, obstacles, managers) may require changes in all tests;
The Entities may not be so easy to set up - The Player may rely on Canvas, EventListeners, or Network, etc. to be constructed;
You are mixing player logic with obstacle manager logic. Both entities are coupled by these tests;
Knockback can be an internal/private property that we’ll need to expose just to test (information leak);

Fourtnelly, Jest has powerful mechanisms that let you Mock even your import statements:

The Test - the fast (decoupled) way:

We’ll need additional steps to setup the mocks in Jest, but it’ll be payed over time:

import { Player } from "../Entities/Player";
import { ObstacleManager } from "../Entities/Obstacles/ObstacleManager";

/* STEP 1 : Setup what jest will be mocking */
jest.mock("../Entities/Player"); 
jest.mock("../Entities/Obstacles/ObstacleManager");

describe("Game Tests", () => {

  beforeEach(() => {
    /* STEP 2 : Clear all instances between tests */
    Player.mockClear();
    ObstacleManager.mockClear();    
  });

  test("The player should have a Knockback if hit an obstacle", () => {    
    /* STEP 3 : Creating Spies */
    const knockbackSpy = jest.fn();
    Player.mockImplementation(() => {
      return { checkCollision: (manager) => { return {}; }, 
                Knockback: knockbackSpy };
    });

    // Jest will take care of injecting the dependencies where needed
    const game = new Game(); 

    game.updateGameState();

    expect(knockbackSpy).toBeCalled();
  });
});

Lots of things happening here, but we can summarize as:

Step 1: on line 5, it’s configuring Jest to replace the import of the Player and ObstacleManager with Mocks;
Step 2: since your Mocks are somehow globals, We are ensuring that they are reset before each test;
Step 3 - This is the tricky and not so obvious part (and why We named this post 😜): Our Game class is decoupled from Player and ObstacleManager, so you can spy on methods that the game is manipulating and test just the game logic itself;

The advantages of this approach:

This test can focus in the game logic itself because is isolated from the entities. The Game object just need to know the interface that the objects will be using (here represented by its functions);
Again, The entities itself don’t need to know about it other. The Player is not coupled with the ObstacleManager anymore, we are just using the “interface” method CheckCollision to ensure that our Game have the appropriate logic;
We don’t need to leak information from the Player, we can check, with the spy function, that our application is calling the Knockback method;

Now it’s easier to write the test for the second statement from our requirement:

  test("The Obstacle should be removed if hit by a Player", () => {    
    const obstacle = {};
    const removeSpy = jest.fn();
    Player.mockImplementation(() => {
      return { checkCollision: (manager) => { return { Obstacle: obstacle }; }, 
                Knockback: jest.fn() };
    });

    ObstacleManager.mockImplementation(() => {
      return { remove: (obstacle) => removeSpy };
    });

    const game = new Game();
    game.updateGameState();

    /* the Method */
    expect(removeSpy).toBeCalledWith(obstacle);
  });

Source

https://jestjs.io/docs/es6-class-mocks

Credits

Revision by Henrique Jardim