Translator: iOSDevLog

The original link

A test suite is an upfront investment that pays off over the life of the system. Today we’ll cover the subject of testing and discuss the different types of tests we can write.

All right, close your eyes. Wait, don’t… It’s hard to read with your eyes closed, but imagine that your application is approaching your first deployment.

As it gets closer and closer, it gets boring and keeps adding features that run in your browser.

There must be a better way.. .

test

When we talk about testing, we are talking about the process of automatically establishing and measuring our assumptions, not the functional assertions about our application.

When we talk about front-end testing in React, we’re referring to the process of asserting what our Reac application renders and how it responds to user interactions.

We’ll discuss three different software testing paradigms: unit testing, functional testing, and integration testing.

Unit testing

Unit testing is testing parts (or units, hence names) of our code so that we can be sure that those specific parts of code work as we expect them to.

For example, we already have some mergers in our application. These mergers consist of a single function that we can assert in different scenarios.

In Reac, unit tests typically do not require a browser, can run quickly (no DOM writing is required), and the assertions themselves are usually simple and concise.

We have focused on answering the question of whether, given a given set of inputs (states and attributes), the output matches what we would expect from a virtual DOM. In this case, we are testing the render output.

A functional test

With functional testing, we focus on testing the behavior of components. For example, if we had a navigation bar with a user login/logout button, we could test our expectations:

  • Given a logged-in user, the navigation renders one with textLogoutThe button
  • Since there is no logged-in user, the navigation will render a textLoginThe button

Functional testing is typically run in isolation (that is, testing component functionality without requiring the rest of the application).

Integration testing

Finally, the last type of test we’ll look at is integration testing. This type of test tests the entire service we apply and tries to replicate the experience end-users have when using our application.

Integration testing is very slow, in order of speed and efficiency, because it requires running expectations against a browser running in real time, because unit and functional tests run faster (especially when functional tests are tested against an in-memory virtual DOM rather than an actual browser rendering).

When testing the response component, we test our expectations of what is contained in the virtual DOM and what is reflected in the actual DOM.

tool

We will use a test library called Jasmine to provide readable test languages and assertions.

As for test runs, there is a general debate around which test runner is easiest/most effective to work with, mainly in Mocha and Jest.

We’re going to use Jest in React in our adventure test because it’s the official (dubious) tester. Most of the code that we’re going to write is going to be in Jasmine. Feel free to use Mocha if it is your test library of choice.

Finally, we’ll use a library we can’t leave: Enzyme, which makes functional testing more fun. Enzyme provides some pretty nice Reac testing utilities that make our assertions easy to write.

Tomorrow, we will have our application setup in place with testing tools so that we can start testing our application and be confident that it works as we expect. See you tomorrow!