Writing your first expectation

Change your describe call to this:

describe('Appointment', () => {
  it('renders the customer first name', () => {
  });
});

The it function defines a single test. The first argument is the description of the test and always starts with a present-tense verb, so that it reads in plain English. The it in the function name refers to the noun you used to name your test suite (in this case, Appointment). In fact, if you run tests now, with npm test, remember, it should make sense:

PASS test/Appointment.test.js
  Appointment
    ? renders the customer first name (1ms)

You can read the describe and it descriptions together as one sentence: Appointment renders the customer first name. You should aim for all of your tests to be readable in this way.

As we add more tests, Jest will show us a little checklist of passing tests.

Empty tests, such as the one we just wrote, always pass. Let's change that now. Let's add an expectation to our test. Change test to read as follows:

it('renders the customer first name', () => {
  expect(document.body.textContent).toMatch('Ashley');
});

This expect call is an example of a fluent API. Like the test description, it reads like plain English. You can read it like this: I expect document.body.textContent toMatch the string Ashley.

Although it might look complicated, it's quite a simple idea: each expectation has an expected value that is compared against a received value. In this example, the expected value is Ashley and the received value is whatever is stored in document.body.textContent.

The toMatch function is called a matcher and there are a whole lot of different matchers that work in different ways. In this case, the expectation passes if document.body.textContent has the word Ashley anywhere within it.

Each individual test can have as many expectations in it as you like, and we'll see examples of multiple expectations in a test later in this chapter.

Before we run this test, spend a minute thinking about the code. You might have guessed that the test will fail. The question is, how will it fail?

Let's run test now, with npm test, and find out:

FAIL test/Appointment.test.js
  Appointment
    ? renders the customer first name (10ms)

  ● Appointment ? renders the customer first name

    expect(received).toMatch(expected)

    Expected value to match:
      "Ashley"
    Received:
      ""

      1 | describe('Appointment', () => {
      2 |   it('renders the customer first name', () => {
    > 3 |     expect(document.body.textContent).toMatch('Ashley');
        |                                       ^
      4 |   });
      5 | });
      6 |

      at Object.toMatch (test/Appointment.test.js:3:39)

There are four parts to the test output that are relevant to us:

• The name of the failing test
• The expected answer
• The actual answer
• The location in the source where the error occurred

All of these help us to pinpoint where our tests failed: document.body.textContent is empty. This isn't surprising really, since we've not done anything to set the body text.

But, hold on a second. Where did document.body come from? No one defined that yet. Shouldn’t we expect the test to fail with an error saying that the document is undefined?

Jest magically includes a DOM implementation for us, which is why we have access to document and document.body. It uses jsdom, a headless implementation of the DOM. We can do test browser interactions on the command line, which is much simpler than involving a browser in our work.

In Jest lingo, this is called the Jest environment and it defaults to jsdom. If you want to verify that this is happening, add the following config to your package.json file:

"jest": {
  "testEnvironment": "node"
}

Re-run tests and observe the different output to convince yourself that JSDOM is no longer present.

Be sure to remove this extra configuration before you continue, as we’ll be relying on the JSDOM environment from now on.