Computer Science · Grade 11

Active learning ideas

Unit Testing in OOP

Active learning works for unit testing because it transforms abstract concepts like behavior verification into concrete, hands-on tasks where students immediately see cause and effect. When students write and run their own tests, they experience firsthand how tests shape design, catch regressions, and build confidence in refactoring, making the value of testing tangible rather than theoretical.

• Ontario Curriculum Expectations
• CS.HS.D.3
• CS.HS.P.5

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

Activity 01

• Problem-Based Learning
• 35 min · Pairs

Pair Programming: Test a Shape Class

Pairs receive a Circle class with radius and area methods. Write at least six tests: valid radii, zero, negative, large values, and exceptions. Run tests iteratively, fix failures, then swap pairs to review and add one more test each.

Explain the importance of unit testing in the software development lifecycle.

Facilitation Tip

During Pair Programming: Test a Shape Class, circulate to ensure pairs alternate roles every 10 minutes so both students engage deeply with both production and test code.

What to look for

Provide students with a simple Python class (e.g., a 'BankAccount' class with deposit and withdraw methods). Ask them to write two unit tests: one for a successful withdrawal and one for an attempted withdrawal exceeding the balance. Review their test code for correct syntax and assertion usage.

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

Activity 02

• Problem-Based Learning
• 45 min · Small Groups

Small Groups: Edge Case Design Challenge

Groups get a StudentGrade class with average method. Brainstorm 8-10 edge cases like empty grades list, all fails, decimals. Write and run tests, then present top three cases to class for vote on most critical.

Design a set of test cases for a given class method, considering edge cases.

Facilitation Tip

For the Small Groups: Edge Case Design Challenge, provide a checklist of common edge cases (empty inputs, boundary values, invalid types) to guide discussions without giving away answers.

What to look for

Pose the question: 'Imagine you are refactoring a complex method in a large application. How would having a comprehensive suite of unit tests for that method benefit your work?' Facilitate a class discussion focusing on safety, confidence, and efficiency.

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

Activity 03

• Problem-Based Learning
• 50 min · Whole Class

Whole Class: TDD Implementation Race

Project a simple Inventory class spec. Class votes on first test, one volunteer codes minimal pass, repeats for next test. Everyone codes along, discusses failures as a group before advancing.

Evaluate how test-driven development (TDD) can improve software quality.

Facilitation Tip

In the Whole Class: TDD Implementation Race, set a strict 20-minute timer for the red-green-refactor cycle to emphasize the rhythm of TDD and prevent over-engineering.

What to look for

Ask students to write down one scenario (an edge case or error condition) that they would specifically test for a given method (e.g., a 'calculate_average' method). Have them briefly explain why this scenario is important to test.

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

Activity 04

• Problem-Based Learning
• 25 min · Individual

Individual: Refactor with Test Net

Provide tested Calculator class. Students refactor one method for efficiency, run existing tests to verify, add two new tests, and document changes in a shared log.

Explain the importance of unit testing in the software development lifecycle.

What to look for

Provide students with a simple Python class (e.g., a 'BankAccount' class with deposit and withdraw methods). Ask them to write two unit tests: one for a successful withdrawal and one for an attempted withdrawal exceeding the balance. Review their test code for correct syntax and assertion usage.

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

A few notes on teaching this unit

Teach unit testing by modeling it live. Show students how you write a test first, watch it fail, then write the minimal code to pass. Emphasize that tests are documentation—use descriptive method names like test_deposit_negative_amount_rejected to clarify intent. Avoid treating tests as an afterthought; integrate them into every coding task so students see their role in the development workflow. Research shows that students grasp testing best when they experience its immediate benefits, not just its long-term promises.

By the end of these activities, students will confidently write unit tests for OOP classes, design edge cases intentionally, and explain how testing cycles improve software quality. They will move from viewing tests as optional checkpoints to recognizing them as essential tools for safe, iterative development.

---

Watch Out for These Misconceptions

• During Pair Programming: Test a Shape Class, watch for students who write tests only after completing the class implementation.

  Pause mid-activity to model writing a test for a single method signature before any production code exists, then ask pairs to refactor their approach to start with tests first.

• During Small Groups: Edge Case Design Challenge, watch for students who focus on trivial inputs (e.g., testing a zero radius) without considering invalid types or negative values.

  Redirect groups to the edge case checklist and ask them to justify why a test for a negative radius is necessary, connecting it to real-world constraints like physical impossibility.

• During Whole Class: TDD Implementation Race, watch for students who perceive TDD as slower because they skip refactoring steps after tests pass.

  Use the class debrief to highlight how refactoring without tests is risky; ask students to share instances where their tests caught issues during refactoring, reinforcing the value of the cycle.

---

Methods used in this brief

• Problem-Based Learning