Later in this chapter, you'll be required to install Node Package Manager (npm) together with a whole host of packages. You'll want to ensure you have a machine capable of running the Node.js environment.

You'll also need access to the command line.

In addition, you should choose a good editor or Integrated Development Environment (IDE) to work with your code.

There's a standard template for creating React apps: the create-react-app application template. This includes some standard dependencies and boilerplate code that all React applications need. However, it also contains some extra items such as favicon.ico, a sample logo, and CSS files. While these are undoubtedly useful, having them here at the very start of a project is at odds with one of the test-driven developer's core principles: You Ain't Gonna Need It (YAGNI).

This principle says that you should hold off adding anything to your project until you're really sure that it's necessary. Perhaps that's when your team adds a user story for it into the iteration, or maybe it's when a customer asks for it. Until then, YAGNI.

It's a theme that runs throughout this book and we'll start right now by...

In this section, we'll discover the TDD cycle for the first time.

We'll start our application by building out an appointment view. We won't get very far; the tests we'll create in this chapter will simply display the customer who made the appointment. As we do so, we'll discuss the TDD process in detail.

We'll build a React functional component called Appointment. It is used for displaying the details of a single appointment in our system. The component will be passed in a data structure that represents Appointment, which we can imagine looks a little something like this:

{
  customer: { firstName: 'Ashley', lastName: 'Jones', phoneNumber: '(123) 555-0123' },
  stylist: 'Jay Speares',
  startsAt: '2019-02-02 09:30...

The next step of the TDD cycle is to refactor your work. This step is often the hardest, because our natural impulse can be to get straight into the next feature. Chasing green, as I like to call it: building more and more functionality is much more exciting. Refactoring, however, is much more zen.

The rule "more haste; less speed" applies to coding, just as in many other areas of life. If you skip the refactoring phase, your code quality will deteriorate. If you develop a habit of skipping refactoring, your code base will soon become difficult to work with.

It takes a lot of personal discipline to consistently refactor, but you will reap the rewards of a code base that remains maintainable as it ages.

Right now, we have some repeated code between our two tests. Let's fix that.

The first test now looks like this:

it('renders the customer first name', () => {
  customer = { firstName: 'Ashley' };
  render(<Appointment customer={customer} />);
  expect(container.textContent).toMatch('Ashley');
});

This is concise and clearly readable.

A good test has three distinct sections:

• Arrange: Sets up test dependencies
• Act: Executes production code under test
• Assert: Checks expectations are met

A great test is not just good but is also the following:

• Short
• Descriptive
• Independent of other tests
• Has no side-effects

We’ve covered a lot of ground, and we have gone into excruciating detail for a very simple test. All of the ground...

So far, we’ve seen a great deal of test-driven development, but not much of React. In this section, we’ll take what we’ve learned about TDD and apply it to learning more React.

Our app at the moment just displays a single thing—a customer’s name. Now, we'll extend it so that we have a view of all appointments that are happening today.

Let's do a little more up-front design. We've got an Appointment component that takes an appointment and displays it. We can build an AppointmentsDayView component around it that takes an array of appointment objects and displays them as a list. It also displays a single Appointment component at any one time, whichever appointment is currently selected. The user can click on an Appointment and it will open up that...

One of the many wonderful things about test-driven development is that it’s teachable. Tests act like a safety harness in our learning: we can build little blocks of understanding, building on top of each other, up and up to ever-greater heights, without fear of falling.

In this chapter, you've learned a lot of the test-driven development experience: the red-green-refactor cycle, triangulation, and Arrange, Act, Assert. You've also learned some design principles such as DRY and YAGNI.

While this is a great start, the journey has only just begun. Coming up next, we'll look at test-driving React forms and building complex user interface designs with our tests acting as scaffold.

• Rename Appointment.js and Appointment.test.js to AppointmentsDayView.js and AppointmentsDayView.test.js. While it's fine to include multiple components in one file if they form a hierarchy, you should always name the file after the root component for that hierarchy.
• Complete the Appointment component by displaying the following fields on the page. You should use a table HTML element to give the data some visual structure. This shouldn't affect how you write your tests:
  • Customer last name, using the lastName field
  • Customer telephone number, using the phoneNumber field
  • Stylist name, using the stylist field
  • Salon service, using the service field
  • Appointment notes, using the notes field

• Add a heading to Appointment to make it clear which appointment time is being viewed.
• There is some repeated sample data...

• Node.js: https://nodejs.org/en/
• Correctly configuring the Babel env preset: https://babeljs.io/docs/en/babel-preset-env
• Jest documentation on the watch tool: https://jestjs.io/docs/en/cli#watch
• Hooks at a Glance: https://reactjs.org/docs/hooks-overview.html