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.

• Grade 11
• Computer Science
• 4 activities
• 25 min–50 min

Learning Objectives

1. Design a suite of unit tests for a given class, covering normal, boundary, and error conditions.
2. Analyze the output of unit tests to identify and debug defects in object-oriented code.
3. Evaluate the effectiveness of different testing strategies, such as TDD, in improving code quality.
4. Create reusable test fixtures and assertion methods to streamline the unit testing process.
5. Explain the role of unit testing in maintaining the integrity of object-oriented software during refactoring.

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.

Prepare & details

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.

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

Prepare & details

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.

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

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

Prepare & details

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.

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

Prepare & details

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

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

What to Expect

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

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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.

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Assessment Ideas

Quick Check

After Pair Programming: Test a Shape Class, collect students’ test files and review them for a mix of normal cases (e.g., area of a square) and edge cases (e.g., negative side length). Check for clear assertion messages and proper use of setup methods in unittest or fixtures in pytest.

Discussion Prompt

During Small Groups: Edge Case Design Challenge, circulate and ask groups to present one edge case they tested and why it matters. Listen for explanations that tie the case to potential bugs or invalid states, assessing their ability to connect testing to real-world constraints.

Exit Ticket

After Whole Class: TDD Implementation Race, ask students to submit a short reflection on how their approach to testing changed during the activity. Look for mentions of test-first habits, awareness of edge cases, or confidence in refactoring, indicating growing ownership of the TDD process.

Extensions & Scaffolding

• Challenge: Ask students to write a parameterized test suite for the Shape Class that tests multiple shapes (Circle, Square) against a shared interface, then compare with a peer’s implementation.
• Scaffolding: Provide a partially completed test file with missing assertions or edge cases for students to fill in, reducing cognitive load while guiding them toward meaningful coverage.
• Deeper exploration: Introduce mutation testing tools like 'mutmut' for Python to show how test suites can be analyzed for effectiveness, discussing what makes a test suite robust versus redundant.

Key Vocabulary

Unit Test	A small, automated piece of code designed to test a specific, isolated part (a unit) of a program, typically a method or function.
Test Case	A set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly.
Assertion	A statement in a unit test that checks if a specific condition is true; if false, the test fails.
Test Fixture	A fixed state or set of conditions that a unit test runs against, often involving setup and teardown procedures.
Test-Driven Development (TDD)	A software development process where tests are written before the actual code, guiding development and ensuring testability.