Test-Driven Development (TDD)

Active learning works for Test-Driven Development because it requires students to experience the cognitive shift from writing requirements as tests first to implementing code second. TDD’s Red-Green-Refactor cycle relies on hands-on practice to internalize the value of early error detection, which lectures alone cannot convey.

• Year 10
• Technologies
• 4 activities
• 25 min–45 min

Learning Objectives

1. Design a suite of unit tests for a given Python function that calculates the area of a rectangle.
2. Analyze the Red-Green-Refactor cycle by identifying specific code changes made at each stage.
3. Evaluate the impact of TDD on the number of bugs found in a small software project compared to traditional development.
4. Justify the practice of writing tests before implementing code by explaining how it serves as a design specification.
5. Create a simple program using TDD, demonstrating the process from writing a failing test to refactoring the code.

Problem-Based Learning

⏱ 35 min·Pairs

Pair Programming: TDD for String Validator

Pairs write failing tests for functions validating email formats or palindromes. They implement code to pass tests, then refactor for efficiency. Pairs swap code with neighbors to run tests and provide feedback.

Prepare & details

Justify the practice of writing tests before implementing features.

Facilitation Tip: During Pair Programming, circulate and coach pairs to verbalize their thought process when deciding what to test next, ensuring they stay in the TDD cycle rather than reverting to traditional coding.

Setup: Groups at tables with access to research materials

Materials: Problem scenario document, KWL chart or inquiry framework, Resource library, Solution presentation template

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management
• Relationship Skills

Problem-Based Learning

⏱ 45 min·Small Groups

Small Groups: TDD Shopping Cart Challenge

Groups design tests for adding items, calculating totals, and applying discounts. They code iteratively, run tests after each cycle, and document refactorings in a shared log. Groups demo one feature to the class.

Prepare & details

Design a set of unit tests for a given function.

Facilitation Tip: In the Small Groups Shopping Cart Challenge, assign each group a distinct bug (e.g., incorrect tax calculation) to seed into their test suite so they experience how early tests prevent later failures.

Setup: Groups at tables with access to research materials

Materials: Problem scenario document, KWL chart or inquiry framework, Resource library, Solution presentation template

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management
• Relationship Skills

Problem-Based Learning

⏱ 40 min·Whole Class

Whole Class: TDD vs Traditional Coding Race

Divide class into TDD teams and traditional teams to build a simple quiz scorer. Time both approaches, then review bug counts and code quality together. Discuss findings in a class vote.

Prepare & details

Evaluate how TDD impacts the overall quality and maintainability of software.

Facilitation Tip: For the Whole Class Race, use a timer and visible leaderboard to emphasize both speed and correctness, demonstrating that TDD teams often finish faster overall despite the initial test-writing step.

Setup: Groups at tables with access to research materials

Materials: Problem scenario document, KWL chart or inquiry framework, Resource library, Solution presentation template

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management
• Relationship Skills

Problem-Based Learning

⏱ 25 min·Individual

Individual: Personal TDD Portfolio

Students select a function from prior units, write tests first, implement, and refactor alone. They submit test reports and reflections on challenges met.

Prepare & details

Justify the practice of writing tests before implementing features.

Setup: Groups at tables with access to research materials

Materials: Problem scenario document, KWL chart or inquiry framework, Resource library, Solution presentation template

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management
• Relationship Skills

Teaching This Topic

Teach TDD by modeling the process yourself in front of the class, making your thinking explicit as you write a test, watch it fail, and then write minimal code to fix it. Avoid skipping the refactor step—students often see it as optional, but its role in maintaining clean, adaptable code is critical. Research shows that students grasp TDD better when they see its iterative nature as a habit, not a one-time task.

What to Expect

Successful learning looks like students confidently writing failing tests first, implementing just enough code to pass, and then improving structure without breaking functionality. They should articulate why this approach reduces debugging time and improves software quality.

Watch Out for These Misconceptions

Common Misconception

During the Whole Class TDD vs Traditional Coding Race, watch for comments like 'TDD is slower because we spend more time writing tests.'

What to Teach Instead

Redirect by asking students to track bug fixes in both teams: TDD teams will spend less time debugging later, while traditional teams may spend more time fixing issues discovered after implementation. Use the leaderboard to show that TDD teams often finish faster overall.

Common Misconception

During the Small Groups Shopping Cart Challenge, watch for students who write tests after coding or skip writing tests entirely.

What to Teach Instead

Remind them to start by writing a failing test for a core feature, such as calculating subtotals, and only then write the minimal code to pass. Circulate and ask, 'What does your test expect to happen?' to refocus their approach.

Common Misconception

During the Pair Programming String Validator activity, watch for students who treat tests as optional or write them as an afterthought.

What to Teach Instead

Ask pairs to swap roles after each test: the coder writes the test, the reviewer verifies it fails, then they switch. This reinforces that tests drive the development process, not the other way around.

Assessment Ideas

Quick Check

After the Pair Programming String Validator activity, ask each pair to present one test they wrote and explain why it initially failed. Observe if they correctly identified the missing functionality in the code.

Discussion Prompt

During the Whole Class TDD vs Traditional Coding Race, facilitate a mid-race discussion with the prompt: 'How did your team’s approach to testing change the way you coded? Give one example from your experience today.'

Exit Ticket

After the Small Groups Shopping Cart Challenge, ask students to write a one-sentence reflection on one bug their tests caught early, and one benefit of the refactor step they observed during the activity.

Extensions & Scaffolding

• Challenge: Ask students to extend their Shopping Cart tests to include edge cases like empty carts or negative quantities, then refactor the code to handle these cases.
• Scaffolding: Provide pre-written test templates for the String Validator activity with missing assertions, so students focus on test design rather than syntax.
• Deeper: Have students research and present on how TDD is used in industry, focusing on tools like Jest for JavaScript or RSpec for Ruby, and compare them to the Python tools they are using.

Key Vocabulary

Unit Test	A small piece of code designed to verify that a specific, isolated part of a program, like a function, works as expected.
Red-Green-Refactor	The core TDD cycle: write a failing test (Red), write the minimum code to pass the test (Green), then improve the code's design (Refactor).
Assertion	A statement within a test that checks if a condition is true; if false, the test fails.
Test Runner	A tool that automatically executes all defined unit tests and reports which tests passed and which failed.