The pieces work separately. Do they work together? We follow one application promise through unit, integration, API, and browser tests, looking at which dependencies are real and what each scope can prove. The best test plan balances confidence, diagnostic clarity, maintenance, and the cost of running it.

A green test means very little if it stopped before the interesting part happened. We work through promises, rejected requests, loading states, races, fake timers, and condition-based waiting. The recurring question: what tells this test that the behavior it cares about has actually finished?

Did the component behave correctly, or did we merely confirm its internal furniture arrangement? We explore React tests through rendering, interaction, and observable results, including props, effects, providers, network boundaries, and snapshots. A useful test should survive a refactor that leaves the user’s experience unchanged.

A simulated DOM can tell us plenty about an interface, but it doesn’t actually draw the page. We test a widget through roles, labels, keyboard interactions, and visible feedback, then examine where real-browser checks still matter. Finding a button and proving people can use it are related questions, not identical ones.

Testing shouldn’t require emailing real customers or charging actual credit cards. We explore test doubles, dependency boundaries, and the differences between supplying an answer and observing a call. A replacement can make a test safer and clearer—or so accommodating that reality never gets a vote.

The test file exists. What finds it, runs it, and decides whether it failed? We separate runners, assertions, environments, transforms, and watch mode while exploring Jest, Vitest, and Node’s testing support. Configuration starts making more sense when every moving part has an identifiable job.

A test should make its question easy to see. We use Arrange, Act, Assert to separate the situation, the action, and the expected result, then tackle fixtures, hooks, names, and parameterized cases. Three comments aren’t enough if the test still passes for the wrong reason.

Is a unit a function, a file, or whatever fits comfortably in your brain? We test small behavioral promises through inputs, outputs, errors, and mutation. Along the way, we examine useful assertions, edge cases, and why a collection of passing unit tests doesn’t prove the whole application works.

“I clicked it and it worked” is evidence. It’s just evidence with a short memory. We explore what automated tests preserve, how regressions happen, and what a passing test actually proves. Before choosing a testing framework, we need a useful question and a reason to trust the answer.

Time to design a system without beginning with a shopping list of technologies. We take Nervous Robot Pizza Delivery from requirements through data ownership, failure paths, accessibility, growth, and recovery. The series wraps with a practical way to explain not just what you’d build, but why.