Live Instruction · TDD · Jest · Masterschool
Testing in JavaScript —
Live Coding Session with Jest
A live group session introducing Masterschool students to test-driven development — covering the red/green/refactor cycle, unit vs. integration tests, and a hands-on code-along building and passing a Jest test from scratch.
The Session
Where theory meets the terminal
This session was timed to meet students at a critical transition point in the Masterschool curriculum — just before the React/Redux capstone project, which introduced Jest testing for the first time. The goal was not to make students testing experts; it was to give them enough conceptual grounding and hands-on exposure that they would not be caught off guard when the test runner lit up red.
The session opened by surfacing a problem students already knew: manual testing is slow and incomplete. Clicking through the browser, filling out forms, waiting for timers — students recognized these friction points immediately from their own projects. That shared frustration became the entry point for why automated testing exists.
From there, the session moved through vocabulary, the red/green/refactor cycle, and directly into a live code-along — setting up Jest from scratch, writing a failing test, implementing the function to make it pass, and reading exactly what the terminal output was communicating at each step.
~40
minutes · live group session
Testing in JavaScript
Jest · TDD · Unit Tests · Integration Tests
Live code-along · Q&A throughout
Learning Goals
What students were meant to walk away with
Five goals shaped what to explain, what to skip, and how much time to spend on the code-along versus the conceptual framing.
Understand Testing and Why It Matters
Frame automated testing as a programmatic way to validate expectations — not just a tool, but a shift in how you think about code quality and confidence when shipping features.
Learn the Types of Tests
Distinguish unit tests (one function in isolation) from integration tests (multiple units working together) — and understand why unit tests make up the bulk of any real test suite.
Recognize the Importance of TDD
Understand test-driven development as a methodology — not a tool or framework — that combines testing, coding, and design (refactoring) into a single disciplined cycle.
Understand the Red/Green Workflow
Internalize the loop: write the test first (it fails), write minimum code to pass it, then refactor. Understand why deliberately starting in red matters for the integrity of the process.
Read and Pass Tests
Leave the session able to read Jest output — understand what a failing test is telling you, locate where the code needs to change, and write the implementation to make the test go green.
What Was Covered
Session content, in sequence
The Manual Testing Problem
Opened by asking students how they currently verified that their code worked. Console.log, clicking around in the browser, waiting for timers to count down — they recognized every example. The UdaciRacer project came up: just to test one function, you had to pick two cars, select a track, start the race, and wait for it to finish. That's five minutes of manual work per test run. Automated testing exists because that doesn't scale.
What a Test Actually Is
Framed testing as validating an expectation. Engineers crash-test cars and stress airplane wings to failure before they're trusted in the field — not because they expect failure, but because finding the breaking point in a controlled environment is the only way to build justified confidence. The same logic applies to code: the failure isn't bad, it's informative.
Vocabulary: The Testing Lexicon
Covered TDD, assertion, assertion library, testing framework, red/green testing, unit test, and integration test — giving students the language to read documentation, follow the React testing workshop, and talk about testing clearly in a technical interview.
Test-Driven Development and the Red/Green Cycle
Introduced TDD as a methodology, not a library. Walked through the six-step cycle: think and write the test → red (fail with no implementation) → green (pass with minimum code) → green (ensure no old tests break) → refactor → repeat. Used the goal-setting analogy: writing a goal down doesn't mean you've done the work. The test is the goal; the implementation is the work.
Live Code-Along: findHighestScoringStudent()
Built a Jest test suite from the terminal up — npm init, install jest as a dev dependency, create src/main.js with an empty function stub, create tests/main.test.js, configure the package.json test script, write the describe/it/expect structure, run the failing test, implement the for-loop solution to pass it. Students followed in VS Code.
Jest Matchers: toBe vs. toEqual
Explained why toEqual() is required when comparing objects — each object has its own memory reference, so toBe() checks reference equality, not content equality. toEqual() recursively checks every property and value, which is what you actually want when asserting on a returned student object.
The Code-Along
From empty folder to passing test
The code-along centered on a single function: findHighestScoringStudent() — takes an array of student objects with names and scores, returns the highest scorer. Simple enough to implement
in a few minutes, but rich enough to demonstrate the complete TDD workflow end to end.
Students started with an empty function stub and a test written against it. Running npm test returned undefined — exactly the point.
The test was not broken; the function had no return statement. The terminal output told them precisely what was missing.
Once the for-loop implementation landed — starting at index 1, comparing each score against the current leader, updating on each higher score, returning the winner — the test went green. The checkmark in the terminal made the red/green cycle concrete rather than theoretical.
The session closed by connecting this directly to the next step: Kent C. Dodds' React testing workshop, which students would encounter in the React/Redux project. Same pattern — tests pre-written, students responsible for writing the code to make them pass. This session was the on-ramp.
# 1. Initialize the project
npm init -y
# 2. Install Jest
npm install --save-dev jest
# 3. Run the tests
npm test
FAIL tests/main.test.js
Expected: { name: "Catarina Lima", score: 9.7 }
Received: undefined
→ Red phase: expected
✓ should return student with highest score
1 passing (1ms)
→ Green phase: achieved
Student Questions
What the Q&A revealed
The questions students asked showed exactly where the conceptual gaps were — and which ideas had already landed.
When is testing actually worth it?
A student asked whether a simple Hello World example warranted a test. The honest answer: even small projects benefit once they have interactive logic — forms, timers, state. The UdaciRacer project came up again: one manual test cycle took 5–10 minutes. Running that five times in a coding session adds up fast. Automated tests run in milliseconds.
How do you know when you have tested enough?
A student introduced branch coverage — the idea that if a function has conditional logic, you need tests for every branch to achieve full coverage. Brief discussion of how Jest can report coverage percentages. Flagged as a topic the React testing workshop would go deeper on.
Can you test UI components?
A student asked about testing conditional rendering — components that appear or disappear based on state or button clicks. Previewed snapshot testing (does this component render?), event-firing tests (does this click handler fire?), and async component testing for API-dependent UI.
What about testing Redux?
The discussion extended to Redux — reducers, actions, store updates. Pointed students toward the Kent C. Dodds workshop, which covered both React testing and React + Redux testing as structured exercises using the same red/green format introduced in this session.
Reflection
What this session demonstrates
Testing is one of those topics where students can read the documentation, follow the syntax, and still have no intuition for why the workflow is designed the way it is. The red/green/refactor cycle only makes sense once you have felt the discomfort of not knowing whether your code actually works — and recognized that starting in failure is the point, not a problem to avoid.
The instructional decision here was to anchor the session in that discomfort first — surfacing the manual testing frustration students already owned — before introducing the solution. By the time Jest appeared, students understood the problem it was solving, not just how to install it.
The code-along format served a specific purpose: watching the terminal go from red to green is qualitatively
different from reading about it. Students needed to see undefined returned by a failing test, understand what it was telling them, and then experience the implementation as the
direct answer to what the assertion was asking for. The terminal output was the teacher; the code was the response.
TDD
methodology · not just a tool
Jest · Node.js · npm
Unit Testing · Integration Testing
Red / Green / Refactor
Interested in working together?
I'm open to remote opportunities in customer education, technical instructional design, and product enablement.