Technologies · Year 10

Active learning ideas

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.

• ACARA Content Descriptions
• AC9DT10P05

• 25–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• 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.

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.

What to look for

Present students with a simple Python function (e.g., `add(a, b)`). Ask them to write one unit test for this function using a testing framework like `unittest` or `pytest`. Observe if the test correctly asserts the expected output for given inputs.

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

Activity 02

• 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.

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.

What to look for

Facilitate a class discussion using the prompt: 'Imagine you are building a calculator application. What is one potential bug you might catch early by writing a test *before* coding the addition function? Explain your test and why it would fail initially.'

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

Activity 03

• 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.

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.

What to look for

On an exit ticket, ask students to describe one benefit of the 'Refactor' step in the Red-Green-Refactor cycle. Then, ask them to list one situation where TDD might be less efficient than traditional coding.

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

Activity 04

• 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.

Justify the practice of writing tests before implementing features.

What to look for

Present students with a simple Python function (e.g., `add(a, b)`). Ask them to write one unit test for this function using a testing framework like `unittest` or `pytest`. Observe if the test correctly asserts the expected output for given inputs.

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

A few notes on teaching this unit

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.

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

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

  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.

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

  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.

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

  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.

---

Methods used in this brief

• Problem-Based Learning