Chapter 10

Tests

A test is a robot that uses your component the way a person would, every time you change anything, and tells you the second something stops working. Nobody likes writing them; everybody likes having them.

Updated 5 Nov 2026Pega 24 – 26

Words you will meet

Jest
npm run verify

On this page4

01Why test a button?
02A test, in plain English
03The four checks
04The habit

The idea

A smoke alarm, not an exam.

Today the button works. Next month somebody changes the shared styling, or tidies the code, and it quietly breaks. Nobody notices until a user clicks it. Tests remove that gap: each time they run, the robot clicks the button and checks the message appears. If it does not, you hear about it in seconds, on your laptop, not from a user.

The tools here are Jest (the runner) and Testing Library (the robot hands). They are already in the project.

Read

A test, in plain English.

Each it(…) is one sentence about the button, then the steps that prove it. Read the sentences first; the code is only the proof.

demo.test.tsx

// demo.test.tsximport { render, screen, fireEvent } from '@testing-library/react';import { composeStories } from '@storybook/react';import '@testing-library/jest-dom'; import * as DemoStories from './demo.stories';import { configProps } from './mock'; // Reuse the Storybook examples as the things to test.const { Default, Disabled, Hidden } = composeStories(DemoStories); describe('AcmeUICelebrateButton', () => {  it('shows the configured text', () => {    render(<Default />);    expect(screen.getByRole('button', { name: configProps.buttonText })).toBeVisible();  });   it('shows the message after a click', () => {    render(<Default />);    fireEvent.click(screen.getByRole('button', { name: configProps.buttonText }));    expect(screen.getByText(configProps.celebrationText)).toBeVisible();  });   it('does nothing when disabled', () => {    render(<Disabled />);    expect(screen.getByRole('button', { name: configProps.buttonText })).toBeDisabled();  });   it('draws nothing when hidden', () => {    render(<Hidden />);    expect(screen.queryByRole('button')).not.toBeInTheDocument();  });});

Play

Four checks. Break one on purpose.

Before you commit, one command runs four checks in order. Pick something to do to the code, then run it. A problem in an early check stops the line, so the later ones never run.

npm run verifyTry it: sabotage the code, then run it

First, do something to the code…

Everything is fineGive a prop the wrong typeLeave an unused variableBreak the click behaviour

1Type checknpm run typecheck
Reads every file and checks the types line up. Must report 0 errors.
2Lintnpm run lint
Checks code style and common mistakes against the project’s rules.
3Unit testsnpm test
Renders each component, clicks it, and checks what happens.
4Hub testsnpm run test:hub
Tests the Deployment Hub tool that publishes components.

Commands

The habit.

npm test: Run every component’s tests.
npm test -- <path>: Run the tests of one component. The fast one while you work.
npm run typecheck: Check the types. Must report 0 errors.
npm run lint: Check style and common mistakes. lint:fix repairs what it can.
npm run verify: All of it, in order. What CI runs. Do this before every commit.
npm run coverage: Run the tests and report which lines they touched.

The one habit worth having: run npm run verify before every commit. If it passes on your machine, the same check in your team's pipeline will pass too.

Green across the board means the button is built, shown and checked. Next, the part that makes it real: getting it onto a Pega server.

Your turn

Questions and comments

Stuck on something, or have a thought? Write it here. To talk about one part, use the Comment button under that section's heading.