Cómo probamos nuestra UI React / Redux, y por qué nos ayuda a movernos rápidamente

Page-level integration tests

Now that all of our units are tested, we need to make sure they fit together correctly. The goal of the page-level integration tests (or "page tests" for short), are to verify that React components are interacting correctly, and that React and Redux are working together correctly.

Tools we need

There were two problems we need to solve to write page tests.

We need a way to generally mock out our REST API calls. We created the AjaxManager which intercepts all calls to $.ajax and provides methods to make a request wait, succeed, or fail.

We also need a way to programmatically wait for our UI to change before taking the next step in the test. We created TestStepBuilder, which is a tool that that allows us to write tests that wait for conditions to be met before taking more steps.

In the demo game, the asynchronous action is taken on a timer, so there is no example of the AjaxManager here, but it makes use of the TestStepBuilder to step through the tests:

beforeAll(function() {
  this.handbookPage = new HandbookPage();
  this.handbookPage.render(done);
}

afterAll(function() {
    this.handbookPage.cleanUp();
});

it("should start the game of clicking when click on the start button", function(done) {
  new TestStepBuilder()
    .step("Verify game has not started", () => {
      expect(this.handbookPage.getGameStatus()).toEqual("Click to start");
    })
    .waitFor("Start button", () => {
      return this.handbookPage.findStartButton();
    })
    .step("Click the start button", () => {
      this.handbookPage.findStartButton().click();
    })
    .waitFor("ClickGameTable to render", () => {
      return this.handbookPage.findClickGameTable();
    })
    .step("Verify game is in progress", () => {
      expect(this.handbookPage.getGameStatus()).toEqual("In progress...");
    })
    .run(done);
});

it("should continue the game of clicking when click on a green button", function(done) {
  new TestStepBuilder()
    .step("Click a green button", () => {
      expect(this.handbookPage.getScore()).toEqual(0, "score should be 0");

      const $greenButtons = this.handbookPage.$findGreenButtons();
      expect($greenButtons.length).toBeGreaterThan(
        0,
        "should have at least 1 green button at game reset"
      );
      $greenButtons[0].click();
    })
    .waitFor("score to go up", () => this.handbookPage.getScore() > 0)
    .step("Verify score and game status", () => {
      expect(this.handbookPage.getGameStatus()).toEqual("In progress...");
      expect(this.handbookPage.getScore()).toEqual(1, "score should be 1");
    }).run(done);
});

it("should end the game and show restart button when click on a red button", function(done) {
  new TestStepBuilder()
    .step("Click a red button", () => {
      expect(this.handbookPage.getScore()).toEqual(1, "score should be 1");

      const $redButtons: JQuery = this.handbookPage.$findRedButtons();
      expect($redButtons.length).toBeGreaterThan(
        0,
        "should be at least one red button after green was clicked"
      );
      $redButtons[0].click();
    })
    .waitFor("Restart button to show", () => {
      this.handbookPage.findRestartButton();
    })
    .step("Verify that the game is over", () => {
      expect(this.handbookPage.getScore()).toEqual(1, "score should stay 1");
      expect(this.handbookPage.getGameStatus()).toEqual("GAME OVER");
    }).run(done);
});

Page object design pattern

In the sample code above, you will notice that the code is agnostic to the page implementation.

We made use of a design pattern documented by Selenium called page object design pattern. In the sample code, HandbookPage is a page object which wraps our implementation of the React handbook page component, and we access the UI only via the page object in our tests.

This decoupling has two advantages.

1. It makes our tests easier to read.
2. If we ever change the implementation of the page, we only need to update the page object and not the tests.

This way the page tests only describe how the page should be tested, and the implementation details are encapsulated in the page object.

End-to-end system tests

In end-to-end UI system tests, we spin up a Qumulo cluster and exercise our UI. We use the same tools as in our page tests, simulating user actions and inspecting the UI using page objects, and work through test steps using TestStepBuilder.

The goal of the systest is to verify that the API is behaving correctly by exercising the UI. There tends to be a lot of overlap between the page tests and end-to-end tests. Usually, the page tests focus on all the different possible asynchronous events (such as network disconnects), whereas the systest specifically checks that the UI and REST API are making the correct assumptions about one another.

Tests help us move fast

Tests help us move fast because they help us produce less bugs, so our workflow gets interrupted less by bug fixes, which means we focus on more development.

Over the last year, we moved away from a model with a layer of unit-ish integration tests and a layer of system tests. In this old model, the "unit" tests had too many dependencies which makes them fragile, while the system tests took too much effort to run regularly during development.

We learned a lot of lessons from this Google Testing Blog post, which describes all the reasons why we moved to the new model with three layers of tests. Today when a unit test fails, it gives us very specific information on what was broken. The TypeScript compiler ensures that our code is syntactically and semantically fitting together correctly, and the page tests check that our React components and Redux code have the correct assumptions about each other. This leaves the system tests to have a much smaller job of ensuring the REST API contracts rather than trying to verify correctness in our UI systems.

Good testing practices have helped us move faster because we are confident in our code as it grows and evolves over time, and the way we break up the tests today makes them easier to write and maintain while giving us much more targeted information when tests fail. We continue to drive for better ways to develop our code, and we hope to share more as we continue our learning!