Don´t use Singleton Pattern in your unit tests

Abú-Bakr Pereira Kebé — Sat, 12 Jun 2021 14:35:07 +0000

What is Singleton Pattern?

Is a design pattern that restricts the instantiation of a class to a single instance. This is useful when one object is needed to coordinate actions across the system exemple custom spiner and services. Through this design pattern, the singleton class ensures that it´s only instantiate once, and can provide easy access to the single instante.

Unit Testing

Is a type of software testing where individual units or componentes of a software are tested. Unit tests isolate a section of code and verify its correctness. A unit test may be an individual function, method, procedure, module or object.

Why do some programmers use singleton in testing?

Some programmers use Singleton in their tests with the intention of using the DRY (Don´t repeat yourself) principle by instantiating the classes that will be used in the tests only once.

So, why don't use design pattern singleton in Unit tests?

Considering that one of the best practices in unit testing is that tests should be independent and in case of any change in one test the others should not be affected, the singleton pattern hinders testability.

Singletons cause implicit dependencies between conceptually independent units of code. This is problematic both because they are hidden and because they introduce unnecessary coupling between units.

As there is no control over creation, a clean instance of the object cannot be used for each test.

Example

I'm going to use TypeScript and Jasmine testing framework in this example.

State.ts Model

export class State {
  id: number;
  status: string;
  static instance:State;

  constructor(args: {id:number,status: string}) {
    this.id = args.id;
    this.status = args.status;
  }

  static getInstance():State{
    if(!State.instance){
      State.instance = new State({id:1995,status:'LOADING'});
    }
    return State.instance;
  }
}

state.spec.ts

import { State } from .....;

describe('State', () => {
  let state:State = State.getInstance();

  it('UT1 - should state id and status be correct', () => {
    expect(state.id).toEqual(1995); // Will always pass
    expect(state.status).toEqual('LOADING'); // Will always pass
    state.status = 'STOP';
  });

  it('UT2 - should state status be LOADING', () => {
    expect(state.status).toEqual('LOADING'); // It will fail whenever UT1 is run first because the state will always change to STOP
  });

});

UT1 (Unit Test 1) and UT2 share state of the same instance of a class causing unnecessary coupling between unit tests.

To prevent this from happening we need to perform some setup.

These activities are called setup and teardown (for cleaning up) and Jasmine has function we can use to make this easier.

First we need to add this code in State.ts

static getCleanInstance():State{
    return new State({id:1995,status:'LOADING'});
 }

And now we add this code in state.spec.ts
In each test we get a new instance of state eliminating the dependency between tests.

let state:State;
  beforeEach(() => {
     state = State.getCleanInstance();
  });

Conclusion

Singleton classes do not allow for Test Driven Development (TDD) The laws of TDD.

Unit testing depends on tests being independent of one another, so the tests can be run in any order and the program can be set to a known state before the execution of every unit test. Once you have introduced singletons with mutable state, this may be hard to achieve. In addition, such globally accessible persistent state makes it harder to reason about the code, especially in a multithreaded environment.

The Singleton pattern solves many of your problems. You know that you only need a single instance. You have a guarantee that this instance is initialized before it’s used. It keeps your design simple by having a global access point, but don’t use in your unit tests.

Cheers ✌️,
Bc.

The laws of TDD

Abú-Bakr Pereira Kebé — Sun, 14 Mar 2021 11:30:40 +0000

What is TDD?

TDD - Test Driven Development is a software development approach in which test cases are developed to specify and validate what the code will do. In TDD the tests are not done at the end of the software development, the tests are done before writing any production code.

Why use TDD?

Is your code difficult to test?
Don't you know if you have 100% test coverage on the project?
Are you afraid to make changes to the project because you don't know where it will go wrong?

TDD solves these and other problems because with the laws of tdd every single line of code that you write will be tested.

The three laws of TDD

1.You are not allowed to write any production code until you have first written a failing unit test;
2.You are not allowed to write more of a unit test than is sufficient to fail and not compiling is failing;
3.You are not allowed to write more production code that is sufficient to pass currently failing unit test.

You begin by writing a small portion of unit test. But within a few seconds you must mention the name of some class or function you have not written yet, thus causing the unit test to fail to complete. So you must write production code that makes the test compile. But you cant write any more code than that, so you start writing more unit test code.

Round and round the cycle you go. Adding a bit to the test code. Adding a bit to the production code. The two code streams grow simultaneously into complementary components. The tests fit the production code like an antibody fits an antigen.

Conclusion

TDD allows us to be more productive since the project only grows “if I can say so” after all the tests have passed.

Once the TDD is embraced it will be a step towards the Clean Code.

In the TDD scenario developers need to be very disciplined because sometimes when the calendar starts to get tight some tests may start to be ignored and if you haven't tested the code how will you know there is a hidden bug ?.

Cheers,
Bc.

DEV Community: Abú-Bakr Pereira Kebé

Don´t use Singleton Pattern in your unit tests

What is Singleton Pattern?

Unit Testing

Why do some programmers use singleton in testing?

So, why don't use design pattern singleton in Unit tests?

Example

Conclusion

The laws of TDD

What is TDD?

Why use TDD?

The three laws of TDD

Conclusion