Unit tests are a challenging topic, with many interconnected aspects that make it difficult for beginners. If your impression is that they are time-consuming to write, provide only meaningless validation, or require a lot of additional effort in case of code refactoring, then chances are that you haven’t seen a well-executed unit tests approach so far. This article provides a simple example that shows that none of those issues has to affect your code. What is testability Testability is an informal measure of how easy it is to write tests for code. There is no precise measure that would allow us to compare code. For me, a good approximation of testability is: how easy it is for me to plan and write unit tests and how much test code do I need to write to get close-to-perfect coverage of my application logic As you see, it’s a bit subjective. In this sense, it’s similar to readability—some patterns are clearly better or worse, whereas in some other cases, it’s mostly a matter of personal preference. Same as in the case of readability: after you spend enough time looking at the code through this lens, you will develop an intuition about how testable different approaches are. Until then, it’s a good idea to follow the recommendations of others while occasionally checking whether the code is easy to test. In short, if you struggle to find a way to write tests for your code, it’s likely suffering from low testability. What are units Units are a small piece of code that you can think about in isolation from the rest of the application. They can be classes, functions, or components. A good unit can be defined as one that: has a name that matches its purpose, considers inputs, outputs and possible states, and fits well with other units in your application. Some common issues that make the unit of your code bad are as follows: tight coupling between different units—instead of following well-defined methods of accessing one another, the units depend on the internal details (like data structure) of other units units that put some values on the global scope—for other code to either override accidentally or use directly unclear purpose—for example, a class called keeps code that rounds numbers, generates unique ID, and can keep anything and everything else utils Example: singleton with global configuration Singleton is a software design pattern that allows only one instance of the object to exist in the application. For the rest of the article, we will use an example of a global configuration that we want to be the same across the entire application. Our example is a perfect use case for singleton— we centralize settings in one place but without putting data directly on the global scope. The focus is mostly focused on the values—the initialization part will always be done only once in the application, and in the first iteration, it can be just hard-coded. reading Testable class with tests To start, let’s create a simple class: export class Configuration {
  settings = [
    { name: "language", value: "en" },
    { name: "debug", value: false },
  ];

  getSetting(name) {
    const setting = this.settings.find(
      (value) => value.name === name
    );

    return setting.value;
  }
} For adding tests, I follow the example from . The test file is: my older article import { Configuration } from "../configuration.js";

describe("Configuration", () => {
  let configuration;

  beforeEach(() => {
    configuration = new Configuration();
  });

  it("should return hard-coded settings", () => {
    expect(configuration.getSetting("language")).toEqual("en");
    expect(configuration.getSetting("debug")).toEqual(false);
  });
}); You can find the code at the branch. initial-implementation If the application life ended here, the effort put into setting up testing infrastructure and writing the test was mostly pointless: we don’t need any safety measure to make sure hard-coded values are returned as expected. Unit tests become useful when we evolve our code and when we want to make sure parts of the logic are changed while others stay the same. some First refactoring: setting data from outside Firstly, let's make the class more dynamic. We’ll introduce a method to initialize the configuration. The idea is that some other part of the application will get the correct values, and the responsibility of the class will be to keep and provide their values to the rest of the application. Configuration Updated code: export class Configuration {
  settings = [];

  init(settings) {
    this.settings = settings;
  }

  getSetting(name) {
    const setting = this.settings.find(
      (value) => value.name === name
    );

    return setting.value;
  }
} As you can see, the change in the code is pretty small, but the class is much more versatile—instead of hard-coding setting values, it will support whatever is set with the call. init Updated tests: import { Configuration } from "../configuration.js";

describe("Configuration", () => {
  let configuration;

  beforeEach(() => {
    configuration = new Configuration();
  });

  it("should return settings provided in init", () => {
    configuration.init([
      { name: "language", value: "en" },
      { name: "debug", value: false },
    ]);

    expect(configuration.getSetting("language")).toEqual("en");
    expect(configuration.getSetting("debug")).toEqual(false);
  });
}); More flexible logic requires more code in tests. In this test implementation, our tests are running all the code we have, but there are two aspects that are not made explicit: Do we support rerunning the method? The code, as it is right now, would work just fine, but one could imagine a case where we would want our logic to ignore reruns or maybe throw an error. init We don’t check whether the settings are read from the values that were provided in the call. It could be that we have some hardcoded values that happen to match what we have in our test. init To make our tests more complete, let’s reinitiate the config with different values: import { Configuration } from "../configuration.js";

describe("Configuration", () => {
  let configuration;

  beforeEach(() => {
    configuration = new Configuration();
  });

  it("should return settings provided in init", () => {
    configuration.init([
      { name: "language", value: "en" },
      { name: "debug", value: false },
    ]);

    expect(configuration.getSetting("language")).toEqual("en");
    expect(configuration.getSetting("debug")).toEqual(false);

    // reinitiate with other values
    configuration.init([
      { name: "language", value: "es" },
      { name: "debug", value: true },
    ]);

    expect(configuration.getSetting("language")).toEqual("es");
    expect(configuration.getSetting("debug")).toEqual(true);
  });
}); Now our tests are checking all the important aspects of the code. You can find this version of the code in branch. initable-configuration Second refactoring: changing data structure If you wondered why we keep the settings as an array, you have a good point: it doesn’t fit the purpose well. We will refactor the data structure now into something that makes much more sense: an object. Update code: export class Configuration {
  settings = {};

  init(settings) {
    this.settings = settings;
  }

  getSetting(name) {
    return this.settings[name];
  }
} The data structure change made our code simpler and more resilient—it will not throw an error when you try to read a nonexistent setting. Both things are strong indicators that this refactoring was a good idea. The code change requires us to update the calls in the unit tests: init import { Configuration } from "../configuration.js";

describe("Configuration", () => {
  let configuration;

  beforeEach(() => {
    configuration = new Configuration();
  });

  it("should return settings provided in init", () => {
    configuration.init({
      language: "en",
      debug: false,
    });

    expect(configuration.getSetting("language")).toEqual("en");
    expect(configuration.getSetting("debug")).toEqual(false);

    // reinitiate with other values
    configuration.init({
      language: "es",
      debug: true,
    });

    expect(configuration.getSetting("language")).toEqual("es");
    expect(configuration.getSetting("debug")).toEqual(true);
  });
}); You can find the code in branch. object-based-approach Third refactoring: more testable class On its own, this class is pretty testable. Unfortunately, if you used it in other classes, it wouldn't be easy to mock. We can address it by making the interface of the class even more explicit: export class Configuration {
  settings = {};

  init(settings) {
    this.settings = settings;
  }

  getLanguage() {
    return this.settings["language"];
  }

  getDebug() {
    return this.settings["debug"];
  }
} Right now, we have two different methods to read each of the settings. Thanks to this change, mocking the object will be very easy and clear to read: configuration …
spyOn(configuration, ‘getLanguage’).and.returnValue(‘en’);
… The class’s own tests gets a bit more explicit as well: import { Configuration } from "../configuration.js";

describe("Configuration", () => {
  let configuration;

  beforeEach(() => {
    configuration = new Configuration();
  });

  it("should return settings provided in init", () => {
    configuration.init({
      language: "en",
      debug: false,
    });

    expect(configuration.getLanguage()).toEqual("en");
    expect(configuration.getDebug()).toEqual(false);

    // reinitiate with other values
    configuration.init({
      language: "es",
      debug: true,
    });

    expect(configuration.getLanguage()).toEqual("es");
    expect(configuration.getDebug()).toEqual(true);
  });
}); You can find this code at the branch. separate-methods Untestable counter-example Two wrap up, let’s take a look on what would be an untestable approach to the same class, using our final data model: an object: export class Configuration {
  settings = {
      language: "es",
      debug: true,
    };
} Those values can be read with configuration.settings.language If you are not used to writing unit tests, this solution will likely look more natural to you—after all, we solve the same issue with less code. On the other hand, if we try the same approach with our original data model—the array—the code is still simple: export class Configuration {
  settings = [
    { name: "language", value: "en" },
    { name: "debug", value: false },
  ];
} but reading values gets a bit complicated: configuration.settings.find(
  value => value.name === ‘language’
).value If you had a complete application using the configuration in this way, going from to would be a massive refactoring—requiring changes in every single piece of code that accesses some values from the configuration. And if you had everything covered by unit tests, those tests probably wouldn’t be very meaningful, and there would be even more code to update. array object Conclusion As you can see, by looking at the code from the point of view of testability, we went from a straightforward approach to something much more elaborate and rigid. This is an example of how unit tests impact your design. If we can see such a big impact on one simple class, imagine how different the code will be if you repeat it over years of development. Whether this is a design approach that you want for your project is for you to evaluate. As I explained in an , my main concern is building the right thing in the right way instead of delivering many features quickly. I would recommend this approach if you'd like article about becoming a “fast” developer your project to have long and healthy life—counting in years or decades, to make it easy for new developers to start quickly making changes in your code without fear of breaking things, or to ensure a smooth transition of ownership when you eventually leave the project behind. I’m not arguing that this is of writing code—depending on your goals, this approach may be a bad or a good fit for you. Good counter-examples would be any code that is meant to be discarded soon: the way any prototypes, experiments and proof-of-concepts applications you write for fun Similarly, it’s possible that your incentives are not aligned with the long-term health of the project. Unfortunately, it’s something you can see both on an individual level—you write an application, but some others fix bugs and do the maintenance—and as a company or a freelancer hired to work on a fixed-scope project, but the client didn't budget for taking care of the long term. Are you interested in learning more? One interesting extension of this class would be loading data from a server—something that you would likely want to do in a real-world application. Doing it in a fully testable way would require introducing dependency injection—something that would require a separate article. Let me know in the comments if you are interested in an article like this. Meanwhile, if you would like to learn more about testing, you can sign up to get updates when I publish testing-related content. here Also Published Here

Keeping Your Units Testable in JavaScript

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

3 Steps to Adding End-to-end Tests to Your Project

The Noonification: Reduce Javascript: Master the Basics (1/11/2023)

The Noonification: Satoshi Might Be a Bitcoin ETF Skeptic (1/13/2024)

The Noonification: Small Puddle of Freedom (11/25/2022)

The Noonification: How to Use AI for Your B2B Marketing (11/11/2022)

105 Stories To Learn About Functional Programming

3 Steps to Adding End-to-end Tests to Your Project

The Noonification: Reduce Javascript: Master the Basics (1/11/2023)

The Noonification: Satoshi Might Be a Bitcoin ETF Skeptic (1/13/2024)

The Noonification: Small Puddle of Freedom (11/25/2022)

The Noonification: How to Use AI for Your B2B Marketing (11/11/2022)

105 Stories To Learn About Functional Programming

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps