Test Fixture Decision-Tree

Introduction

In all the web applications, JavaScript interacts with the DOM(Document Object Model) elements at the run time. This interaction between them can be challenging to test. So to test the interaction between JavaScript and DOM operations or elements, a DOM instance is created as a test fixture. The DOM fixture must be similar to the structure expected by the function. Otherwise, the tests might be terminated due to the null exception. 

A test fixture ensures there is a well-known and fixed environment in which tests are run so that results are repeatable. Let's look at a few examples of test fixtures listed below.

• Preparing input data and setup/creation of fake objects.
• Loading a database with a specific set of data.
• Copying a set of files and creating a test fixture will create a set of objects initialized to certain states.

Let’s create a test fixture to replace the background color of an element.

const backgroundColorReplacer = require("../../replacer");

describe("backgroundColorReplacer", () => {
  it("not replace color if no match", () => {
    try {
      const { target, options } = require(`../not-replace-color-if-no-match.js`);
      expect(backgroundColorReplacer(target, options)).toMatchSnapshot();
    } catch (error) {
      expect(error).toMatchSnapshot();
    }
  });

  it("not replace color if no new color specified", () => {
    // ...
  });

  it("replace color when match and opacity defined", () => {
    // ...
  });

  it("replace color when match", () => {
    // ...
  });
});

The above test fixture code groups all the elements we need to replace the background color, runs the tests individually, and replaces the color of a match. Otherwise, it doesn’t replace any color, and the test fails. The image given below shows the output of the above code.

Source

Decision tree

The decision tree helps us decide which hooks, plug-ins, and global test fixtures we should use to create a fixture. The decision tree has a few steps similar to a flow chart, with the conditions divided into further steps based on their evaluation.

When we need to test a setup, we decide whether we run the tests once or multiple times based on the setup. If it needs to be run multiple times, we decide if we share the state of setup with the tests and if we want to share the state, we use react hooks; otherwise, we use global test fixtures. But when we don't want the setup to run only once, we decide whether the setup should affect the tests across all files or not. If yes, we use react hooks; otherwise, we use plain hooks. In this way, we decide on what hooks or fixtures to use to meet the required testing conditions and execute them.