DEV Community: Paul Everitt

React, TypeScript, and TDD Part 3

Paul Everitt — Mon, 28 Jun 2021 17:44:07 +0000

React component development is fun, but it breaks your flow heading over to the browser to poke around. What's a more joyful routine? Staying in a test in your IDE.

That's what this series of posts is about. I'm showing my React+TypeScript+TDD tutorial in the WebStorm Guide, which includes videos+text+code. The previous two articles covered Part 1 and Part 2.

Let's wrap up this series by taking a look at the last two steps in the tutorial: Rich Events and Testing and Presentation and Container Components.

Rich Events and Testing

Our Counter doesn't track any count. We're going to add event handling to a stateful class component by first writing tests during development. First, let's get things set back up.

Getting Setup

From the end of Part 2, we have a Counter component in a file Counter.tsx:

import React, {Component} from "react";

export type CounterProps = {
    label?: string;
    start?: number;
};
const initialState = {count: 0};
export type CounterState = Readonly<typeof initialState>;

export class Counter extends Component<CounterProps, CounterState> {
    readonly state: CounterState = initialState;

    componentDidMount() {
        if (this.props.start) {
            this.setState({
                count: this.props.start,
            });
        }
    }

    render() {
        const {label = "Count"} = this.props;
        return (
            <div>
                <div data-testid="counter-label">{label}</div>
                <div data-testid="counter">
                    {this.state.count}
                </div>
            </div>
        );
    }
}

Side-by-side in our IDE, we have the tests for that component in Counter.test.tsx:

import React from "react";
import {render} from "@testing-library/react";
import {Counter} from "./Counter";

test("should render a label and counter", () => {
    const {getByTestId} = render(<Counter/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
    const counter = getByTestId("counter");
    expect(counter).toBeInTheDocument();
});

test("should render a counter with custom label", () => {
    const {getByTestId} = render(<Counter label={`Current`}/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
});

test("should start at zero", () => {
    const {getByTestId} = render(<Counter/>);
    const counter = getByTestId("counter");
    expect(counter).toHaveTextContent("0");
});

test("should start at another value", () => {
    const {getByTestId} = render(<Counter start={10}/>);
    const counter = getByTestId("counter");
    expect(counter).toHaveTextContent("10");
});

With this in place, our tests pass:

Failing Click Test

Let's start with a failing test that clicks on the count and checks if the number is updated:

import { render, fireEvent } from "@testing-library/react";
// ...

test("should increment the count by one", () => {
  const { getByRole } = render(<Counter />);
  const counter = getByRole("counter");
  expect(counter).toHaveTextContent("0");
  fireEvent.click(counter)
  expect(counter).toHaveTextContent("1");
});

fireEvent, what's that? It's the big idea in this tutorial step. You can pretend to click, or dispatch other DOM events, even without a real browser or "mouse". Jest uses the browser-like JSDOM environment entirely inside NodeJS to fire the event.

This new test fails: the number didn't increment. Which is good!

onClick Handler

The component doesn't handle clicks. Let's head to Counter.tsx and add a click handler on the counter, pointed at a method-like arrow function "field":

    incrementCounter = (event: React.MouseEvent<HTMLElement>) => {
        const inc: number = event.shiftKey ? 10 : 1;
        this.setState({count: this.state.count + inc});
    }

    render() {
        const {label = "Count"} = this.props;
        return (
            <div>
                <div data-testid="counter-label">{label}</div>
                <div data-testid="counter" onClick={this.incrementCounter}>
                    {this.state.count}
                </div>
            </div>
        );
    }

With onClick={this.incrementCounter} we bind to an arrow function, which helps solve the classic "which this is this?" problem. The incrementCounter arrow function uses some good typing on the argument, which can help us spot errors in the logic of the handler.

Allow Event Modifiers

Let's add one more feature: if you click with the Shift key pressed, you increase the count by 10. To help on testing, we'll install the user-event library:

$ npm install @testing-library/user-event @testing-library/dom --save-dev

...then import it at the top of Counter.test.tsx:

import userEvent from "@testing-library/user-event";

The event modifier code is already written above -- we just need a test:

test("should increment the count by ten", () => {
    const {getByTestId} = render(<Counter/>);
    const counter = getByTestId("counter");
    expect(counter).toHaveTextContent("0");
    userEvent.click(counter, { shiftKey: true });
    expect(counter).toHaveTextContent("1");
});

In this test, we changed from fireEvent in testing-library to userEvent in user-event. The click passes in some information saying shiftKey was "pressed".

The test passes!

Presentation and Container Components

Our Counter component has a lot going on inside. React encourages presentation components which have their state and some logic passed in by container components. Let's do so, and along the way, convert the back to a functional component.

As a reminder, this is covered in depth, with a video, in the Guide tutorial step.

Counter State

Let's start with a test. We want to pass the state into component as a prop, thus allowing a starting point for the count. In the should render a label and counter first test, when we change to <Counter count={0}/>, the TypeScript compiler yells at us:

That makes sense: it isn't in the type information as a valid prop. Change the second test to also ask for starting count:

test("should render a label and counter", () => {
    const {getByTestId} = render(<Counter count={0}/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
    const counter = getByTestId("counter");
    expect(counter).toBeInTheDocument();
});

test("should render a counter with custom label", () => {
    const {getByTestId} = render(<Counter label={`Current`} count={0}/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
});

Back in Counter.tsx, let's convert to a dumb, presentational component:

import React from "react";

export type CounterProps = {
    label?: string;
    count: number;
};

export const Counter = ({label = "Count", count}: CounterProps) => {
    return (
        <div>
            <div data-testid="counter-label">{label}</div>
            <div data-testid="counter"
                // onClick={handleClick}
            >
                {count}
            </div>
            {count}
        </div>
    );
};

It's pretty similar, but the count value is passed in, rather than being component state. We also have commented out the star of the show: a callable that increments the counter.

Passing In a Function

We'll tackle that now. But in a bit of a curveball way: we'll pass the handleClick callable into this dumb component. The parent will manage the logic.

Let's model the type information for this prop:

export type CounterProps = {
    label?: string;
    count: number;
    onCounterIncrease: (event: React.MouseEvent<HTMLElement>) => void;
};

Immediately, though, TypeScript gets mad in our first two tests: we're missing a mandatory prop. We fix it by creating mock function and passing it into these two tests:

test("should render a label and counter", () => {
    const handler = jest.fn();
    const {getByTestId} = render(<Counter count={0} onCounterIncrease={handler}/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
    const counter = getByTestId("counter");
    expect(counter).toBeInTheDocument();
});

test("should render a counter with custom label", () => {
    const handler = jest.fn();
    const {getByTestId} = render(<Counter label={`Current`} count={0} onCounterIncrease={handler}/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
});

For our third test -- tracking the click event -- we change the handler to see if it was called:


test("should call the incrementer function", () => {
    const handler = jest.fn();
    const { getByTestId } = render(
        <Counter count={0} onCounterIncrease={handler} />
    );
    const counter = getByTestId("counter");
    fireEvent.click(counter);
    expect(handler).toBeCalledTimes(1);
});

The last section of the tutorial continues to cover more of the refactoring:

Make the dumb component a little smarter by not requiring a callable prop
Changing the parent component to track the updating of the state
Writing tests to make sure the App uses the container and presentation components correctly

Along the way, the tutorial shows how to refactor the type information to correctly model the contract.

Conclusion

And that's a wrap! In this 3 part series, we did a summary of this React+TS+TDD tutorial. We covered quite a bit, and the best part -- we didn't head over to a browser. We stayed in our tool, in the flow, and worked with confidence.

React, TypeScript, and TDD Part 2

Paul Everitt — Wed, 09 Jun 2021 17:24:58 +0000

React component development is kinda fun. What's even...uhhh...funner? Driving your component development from inside a test.

No, I'm serious.

As we saw in the previous article introducing this, React+TDD isn't just about "quality" (scare quotes) and eating your vegetables. Particularly when paired with TypeScript and smart tooling, it's a pleasurable mode of development -- faster, joyful, puppies.

Let's get more specific in this article by going through some of the modes of component development. As a reminder, this article follows a full video+text+code tutorial in the WebStorm Guide.

TSX and ES6

Using React and TypeScript means good JSX (TSX) and ES6+ support, especially in smart editors. We can see this in action from the tutorial step on this subject.

Imagine we have some React code:

import React from "react";

function App() {
    return (
        <div>
            <h1>Hello React</h1>
        </div>
    );
}

export default App;

...and the test that goes with it:

import React from "react";
import {render} from "@testing-library/react";
import App from "./App";

test("renders hello react", () => {
    const {getByText} = render(<App/>);
    const linkElement = getByText(/hello react/i);
    expect(linkElement).toBeInTheDocument();
});

We can then run some tests. Here we see the Jest test runner integrated into a "smart editor", in this case, WebStorm:

Let's do some TDD and show some ES6 features along the way.

Extracted Heading

What's something you do All The Time(tm) in React? Decompose big components into smaller components. Let's extract a Heading component from this App component, starting with a new test. One that fails, of course:

test("renders heading", () => {
  const { getByText } = render(<Heading />);
  const linkElement = getByText(/hello react/i);
  expect(linkElement).toBeInTheDocument();
});

We can't even import our component because...it doesn't exist. Let's now write our first attempt at an extracted Heading component:

import React from "react";

export function Heading() {
    return <h1>Hello React</h1>;
}

When our test adds the import of Heading, the new test will then pass:

Of course, extracting a component into the same file somewhat violates the React community's adherence to "one component per file." Let's move our component to its own Heading.tsx file:

export function Heading() {
  return <h1>Hello React</h1>;
}

...with a companion Heading.test.tsx:

import React from "react";
import {render} from "@testing-library/react";
import {Heading} from "./Heading";

test("renders heading", () => {
    const {getByText} = render(<Heading/>);
    const linkElement = getByText(/hello react/i);
    expect(linkElement).toBeInTheDocument();
});

When we run the test in this file, it passes again:

We need to change our App.tsx to import this Heading component and use it:

import React from "react";
import {Heading} from "./Heading";

function App() {
    return (
        <div>
            <Heading/>
        </div>
    );
}

export default App;

Our test in App.test.tsx still passes -- it doesn't really know that Hello React came from a subcomponent.

We can now show some testing of parent and child components.

Props and Types

That is a boring component. It says the same thing every time! Let's change it so "parent" components can pass in a value for the "name" to say hello to.

We first write a (failing) first test in Heading.test.tsx:

test("renders heading with argument", () => {
  const { getByText } = render(<Heading name={`World`}/>);
  const linkElement = getByText(/hello world/i);
  expect(linkElement).toBeInTheDocument();
});

Thanks to TypeScript and tooling, we "failed faster": it immediately told us, with a red-squiggly, that we violated the contract. Heading doesn't (yet) take a name prop:

Let's head to the Heading component and fix it:

export function Heading({ name }) {
  return <h1>Hello {name}</h1>;
}

Our new test passes. The previous test is broken -- no name was passed in. We'll handle that in a bit.

What's up with the {name} as the function argument? This is ES6 object destructuring, a cool way to pick out the values you want from an argument.

Our test passes but TypeScript is unhappy:

We don't have any type information on the props. We could add the type information inline:

export function Heading({ name }: {name: string}) {
  return <h1>Hello {name}</h1>;
}

It is better, though, to put this in a standalone type or interface, then use that in the function arguments:

type HeadingProps = { name: string };

export function Heading({ name }: HeadingProps) {
  return <h1>Hello {name}</h1>;
}

Let's now look at fixing the first test.

Default Prop Value

We want Heading to accept a name prop but not require it. Sounds like a change to the type definition, marking name as an optional field:

type HeadingProps = { name?: string };

We can then use another ES6 feature -- default values in object destructuring:

export function Heading({name = "React"}: HeadingProps) {
    return <h1>Hello {name}</h1>;
}

With this, Heading will use React as the prop value if the calling component doesn't provide it. Our first test in Heading.test.tsx now passes.

You know who else doesn't provide that prop? Our App component. And guess what -- our tests in App.test.tsx now pass again:

At each step during development of this, we "failed faster" thanks to TypeScript and test-first. Even better -- we have yet to look at the browser. We stayed "in the flow".

Class Components With Props

The React community has become very enthusiastic about functional programming and pure, function-based components. But the class-based component syntax is still there for all the old die-hards. (Narrator: He means himself.)

Let's make a new Counter component, written as a class-based component which takes a single prop. We'll be following along the tutorial step that matches this section. In the next section, we'll introduce state into the class.

Of course, we'll start with a failing Counter.test.tsx test which uses Testing Library's getByTestId query:

import React from "react";
import {render} from "@testing-library/react";
import {Counter} from "./Counter";

test("should render a label and counter", () => {
    const {getByTestId} = render(<Counter/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
    const counter = getByTestId("counter");
    expect(counter).toBeInTheDocument();
});

We create a new Counter.tsx file:

import React, {Component} from "react";

export class Counter extends Component {
    render() {
        return (
            <div>
                <div data-testid="counter-label">Count</div>
                <div data-testid="counter">
          1
        </div>
            </div>
        );
    }
}

Our test passes. But it's boring: we want the label displayed next to the count to be configurable, passed in by the parent as a prop. Here's the (failing) test:

test("should render a counter with custom label", () => {
    const {getByTestId} = render(<Counter label={`Current`}/>);
    const label = getByTestId("counter-label");
    expect(label).toBeInTheDocument();
});

This failed even before I ran the test, as TypeScript told us we broke the contract:

Back in the implementation, we need two things: a type definition for the props then a changed class which uses the prop:

import React, {Component} from "react";

export type CounterProps = { label?: string };

export class Counter extends Component<CounterProps> {
    render() {
        const {label = "Count"} = this.props;
        return (
            <div>
                <div data-testid="counter-label">{label}</div>
                <div data-testid="counter">
                    1
                </div>
            </div>
        );
    }
}

Our Counter tests now pass. We have a class-based Counter component which accepts a prop.

Class Components With State

"Yay, us" in a way, but the Counter doesn't...count. Let's make a stateful class-based component. This section matches the tutorial step for Class Components With State.

What's the first step? Hint: it rhymes with "best". That's right, let's start with a failing test in Counter.test.tsx:

test("should start at zero", () => {
    const {getByTestId} = render(<Counter/>);
    const counter = getByTestId("counter");
    expect(counter).toHaveTextContent("0");
});

Now on to the implementation. When we did the component prop, we wrote a TypeScript type to model the prop shape. Same for the state:

export type CounterState = { count: number };

We then change our Counter class to point to and implement that state:

export class Counter extends Component<CounterProps, CounterState> {
    state: CounterState = {
        count: 0,
    };

    render() {
        const {label = "Count"} = this.props;
        return (
            <div>
                <div data-testid="counter-label">{label}</div>
                <div data-testid="counter">
                    {this.state.count}
                </div>
            </div>
        );
    }
}

Our test passes. The value of the state is done as a class variable, which then meant we got autocomplete on this.state.count. But if we try to do an assignment, we know that React will complain that we didn't use setState.

Fortunately this is something TypeScript can help with. Let's move the initialization of the state to the module scope, then change the type definition:

const initialState = {count: 0};
export type CounterState = Readonly<typeof initialState>;

Our class now points at this initial state:

export class Counter extends Component<CounterProps, CounterState> {
    readonly state: CounterState = initialState;

    render() {
        const {label = "Count"} = this.props;
        return (
            <div>
                <div data-testid="counter-label">{label}</div>
                <div data-testid="counter">
                    {this.state.count}
                </div>
            </div>
        );
    }
}

Our test still passes. Again, this is what's nice about test-driven development: you can make changes with confidence, while staying in the tool.

Let's make a change to allow the starting value of the counter to passed in as a prop. First, a failing test:

test("should start at another value", () => {
    const {getByTestId} = render(<Counter/>);
    const counter = getByTestId("counter");
    expect(counter).toHaveTextContent("10");
});

Not only does the test fail, but TypeScript yells at us about the contract, even before the test is run:

We need to change the type definition for our props:

export type CounterProps = {
    label?: string;
    start?: number;
};

With this in place, we can make a call to setState to update the value. We will do it in a lifecycle method:

componentDidMount() {
    if (this.props.start) {
      this.setState({
        count: this.props.start,
      });
    }
  }

Our test now passes. The counter has a default starting count, but can accept a new one passed in as a prop.

Conclusion

We covered a lot in these three steps: the use of ES6 niceties, type definitions for props and state, and the use of class-based components. All without visiting a browser.

In the third and final installment, we will wire up event handlers and refactor into smarter parent/child components. We'll do both in a way that let both TypeScript and testing help us "fail faster."

React, TypeScript, and TDD

Paul Everitt — Tue, 11 May 2021 20:04:21 +0000

ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Getting a lot better. Those two, in the context of test-driven development, combined with smart tooling? It's hard to find accurate learning materials.

That three-part combination -- React, TypeScript, and TDD -- is the topic of this series. This article is a Part 1 summary of a 10-part video/text/code tutorial on React, TypeScript, and TDD. In two later installments, we’ll recap later steps from the tutorial.

Why Test-Driven Development?

Eat your vegetables!

Test-driven development, or TDD, is pitched as a way to do extra work up front, to improve quality and save time later on. Most people, when told that, hear: “Blah blah extra work blah blah blah” and take a pass.

This tutorial series tries to pitch test-first in a different light: it’s faster and more joyful.

Why is it faster? I’m writing a React component, and I want to see if it works. I leave my editor, go to my browser, click around in the universe, hope I didn’t break something in another route/view. With the style of development pitched in this article, you stay in your smart editor, in the few lines of test code, and watch as things gradually start working.

And don’t even get me started on debugging during component development, aka console.log. Instead, you sit in your test, running under NodeJS, and set breakpoints, as all the gods in the multiverse intended.

Joyful? Testing?

That’s a big claim. But it’s true. Instead of breaking your mental “flow” going between tools and contexts, you stay in your IDE, where you have muscle memory atop muscle memory. Code on the left, test on the right, test output at the bottom.

Mess something up? You’ll fail faster with a broken test or even an IDE squiggly thanks to TypeScript. If you broke something that isn’t the URL being hot reloaded by create-react-app, you’ll know that too. It’s a feeling -- really, I’m not just saying this -- of calm, methodical progress.

Of course, you also get your vegetables into the bargain.

Setup

I won’t belabor the details of getting started: it’s in the tutorial step and quite familiar to anybody who has used Create React App. Still, to get oriented, I’ll show a few things.

What is Create React App (CRA)? Modern React, like anything in frontend development, has gotten awfully fiddly. CRA is a scaffold to create new React projects, using a known set of working packages.

You could master the hundreds of npm packages and configuration yourself, and keep them up-to-date as things change. CRA not only generates a working project for you, it moves the ongoing configuration into their package. Meaning, they will keep it working. (Terms and conditions apply, consult a doctor before tinkering, offer not valid if you eject.)

Creating a new project using npx (the npm command to fetch and run a package) is easy:

$ npx create-react-app my-app --template typescript

Modern IDEs probably automate this for you as part of the New Project wizard.

npx will then fetch the create-react-app package, run it, and pass the template argument saying to generate a package that uses TypeScript. You’ll probably get a laugh out of this self-aware log message:

Installing packages. This might take a couple of minutes.

The command also initializes a git repo, creates a package.json, and does the equivalent of npm install for your generated package. At the time of this writing, the result is a mere 1,063 entries in the node_modules directory.

Thank you CRA for owning all that.

You now have a working Hello World in React and TypeScript. To see it in action, run:

$ npm start

Your IDE probably has a pointy-clicky way to run this. For example in WebStorm and other IntelliJ IDEs:

You’ll see some log messages as the dev server starts, and a browser will open at http://localhost:3000 -- convenient!

Where did “start” come from? Take a look at the “scripts” block in the generated package.json file:

"start": "react-scripts start",

It’s a shortcut to a console script provided by CRA.

But wait, there’s more! With the dev server still running, open src/App.tsx and some text in the <p>, then save. In a second or two, your browser shows the update. CRA is watching for changes, transparently executes the four trillion instructions to change the frontend code, and does a smart reload with the browser.

If you look at all of package.json, you’ll see that it is quite compact.

{
  "name": "react_ts_tdd",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "@types/jest": "^26.0.15",
    "@types/node": "^12.0.0",
    "@types/react": "^17.0.0",
    "@types/react-dom": "^17.0.0",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-scripts": "4.0.3",
    "typescript": "^4.1.2",
    "web-vitals": "^1.0.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Well, “compact” relative to the amount of work it is doing.

The genius of create-react-app lies in moving a bunch of "What the hell is this?" configuration files, into its packages. Thus, they own those decisions and complexity. You can then upgrade those packages and gain new/fixed wiring of all the JavaScript build tools.

Let’s run one more of the scripts CRA provided:

$ npm run-script build

This takes a while, as it hyper-optimizes a generated React site/app in the build directory. This can then be deployed to a server.

Hello Test

“You got me excited about testing, no testing, where’s the testing!” You’re right! Let’s do some testing, following the tutorial step that covers this.

First, some background. I know, I know, I’ll get to a test soon.

CRA is opinionated. It chooses important packages, generates the configuration, and keeps the setup working. For testing, CRA has made three important choices:

Jest as the test runner
jsdom as a simulated browser
react-testing-library for test helpers and an assertion library

Enough ceremony. Let’s run the tests:

$ npm run-script test

It’s running under the watcher, so it tells you it doesn’t have any tests that have changed, based on Git:

Open src/app/App.tsx and change save to reload to save to reload!!. You’ll see output the looks something like this:

The watcher has some options to limit what it looks for, which really helps productivity. This time, change “Learn React” in src/App.tsx to say “Master React”. The watcher re-runs the tests, which now fail:

In an IDE you might get a richer way to look at this. For example, in WebStorm, here’s what the failing test runner looks like:

What’s really happening here? What’s executing? As mentioned earlier, CRA uses Jest as a test running. That makes Jest a...wait for it...test runner. It provides configuration, command flags (such as the watcher), ways to find tests, etc. It also bundles jsdom as the pre-configured test environment, which is a long way to say “browser.”

jsdom is really neat. It’s a fake browser, written in JS, that runs in NodeJS and pretends to render your markup and execute your JavaScript. It’s a super-fast, unobtrusive alternative to Chrome firing up for each test.

Jest also uses testing-library -- specifically, its React integration -- for the format of the tests and the assertions where you check that the code works.

What does that look like? What does an actual test look like? Here is the test that Create React App generates by default:

import React from 'react';
import { render, screen } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});

We’ll see more down below when we really get into TDD. But for now...this is a nice way to work: staying in your editor and failing faster.

Debugging During Testing With NodeJS

We’ve already shown a lot, enough that -- at least for me -- is really compelling for working this “test-first” way. But there’s one more part that clearly beats the alternative: debugging. This is covered in the text and video for the tutorial step on this section. This section shows integration with a particular tool (WebStorm) but concepts apply elsewhere.

Imagine, instead of just an <h1> with a label, we wanted a function that calculated the “greeting”. This function might take an argument for the name to say hello to, and we want to uppercase that name.

We could write the function and insert the call in the heading. Let’s write a test first:

test('generates a label', () => {
  const result = label("React");
  expect(result).toEqual("Hello REACT");
});

The test fails: we haven’t written a label function. In fact, our tool gave us a warning, saying we haven't even imported it:

Let’s now write that label function:

export function label(name) {
    return `Hello ${name.toUpperCase()}`;
}

Once we import it in src/App.test.tsx, the tests now pass again. That’s great, but if we pass it an integer instead of a string:

test('generates a label', () => {
  const result = label(42);
  expect(result).toEqual("Hello REACT");
});

...the test will get angry:

Let’s say we can’t easily figure out the problem. Rather than sprinkling console.log everywhere, we can use...the debugger! Set a breakpoint on the line in the test:

Now run the tests, but executing under the debugger:

Execution will stop on this line in the test. You can choose “Step Into” to jump into the label function and then poke around interactively. You then discover -- duh, integers don’t have a toUpperCase method:

In fact, TypeScript was warning us about this:

As a way to help guard against this, and to “fail faster” in the future, add type information to the name argument for the label function:

export function label(name: string) {
    return `Hello ${name.toUpperCase()}`;
}

Debugging during test writing -- and staying in NodeJS, thus in your tool -- is super-productive. It’s much more productive than console.log the universe, or using the browser debugger.

Conclusion

Writing React components is usually an iterative process: write some code, switch to the browser, click around. When you have problems and need to poke around, it’s...complicated.

The combination of TypeScript, test-first, and smarter tooling gives an alternative. One where you “fail faster” and stay in the flow, code with confidence -- and dare I say, have more fun.

In this first part we set the scene. As the tutorial shows, we’ll get into real component development in the next two parts.