Unit Testing for OOP

Unit testing shifts students from passive program runners to active code validators. When they write tests, they confront assumptions about how code should behave, which strengthens their understanding of both design and debugging. Active learning works here because students practice testing while the code is still small and malleable, making mistakes easier to correct and lessons more immediate.

• 11th Grade
• Computer Science
• 3 activities
• 20 min–45 min

Learning Objectives

1. Design unit tests for a given Java class using JUnit, following the Arrange-Act-Assert pattern.
2. Analyze the output of a unit test suite to identify failing tests and potential code defects.
3. Evaluate the effectiveness of a set of unit tests by calculating code coverage and assessing test case relevance.
4. Create a comprehensive test suite for a simple object-oriented program that demonstrates mastery of testing principles.

Project-Based Learning

⏱ 45 min·Pairs

Test-First Challenge: Write Tests Before the Code

Give pairs the specification for a class (e.g., a Temperature converter with specific conversion methods and edge case behavior) but not the implementation. Pairs write unit tests first, then implement the class to make those tests pass. Debrief on what the exercise revealed about the specification's ambiguities.

Prepare & details

Explain the purpose and benefits of unit testing in software development.

Facilitation Tip: During Test-First Challenge, ask students to swap their written tests with a partner before coding the class, forcing them to verify that test expectations are clear and feasible.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

Project-Based Learning

⏱ 35 min·Individual

Test Suite Audit: Find the Gaps

Provide a class implementation and a partial test suite with obvious gaps (no edge cases, no error conditions tested, happy-path only). Students individually identify at least three missing test cases, write them, and explain what bug each test would catch. The class shares their findings and constructs a more complete test suite together.

Prepare & details

Design effective unit tests for a given class or method.

Facilitation Tip: For the Test Suite Audit, provide a class with missing test cases and ask pairs to identify not just what’s missing, but why those cases matter for correctness.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

Think-Pair-Share

⏱ 20 min·Pairs

Think-Pair-Share: What Makes a Good Unit Test?

Show three test examples--one well-written, one that tests too much at once, one with a trivial assertion. Students individually rank the tests from best to worst and write a rationale. Pairs compare rankings, then the class constructs a shared rubric for what makes a unit test effective.

Prepare & details

Evaluate the quality of a test suite based on its coverage and effectiveness.

Facilitation Tip: In Think-Pair-Share, assign each pair a different unit test example to analyze first, then share their criteria for a 'good' test with the class.

Setup: Standard classroom seating; students turn to a neighbor

Materials: Discussion prompt (projected or printed), Optional: recording sheet for pairs

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

Teaching This Topic

Teach unit testing by making it a habit early. Avoid presenting it as an add-on—frame tests as part of the design process, not a chore. Research shows students grasp testing concepts faster when they write tests before code, even if the tests fail initially. Emphasize that tests are specifications first and validators second. Keep the focus on behavior, not lines of code covered.

What to Expect

Students will move from writing tests that only cover happy paths to crafting suites that probe edge cases and validate behavior systematically. They will use the Arrange-Act-Assert pattern consistently and justify test choices based on code requirements rather than guesswork. By the end, they will see unit tests as documentation that prevents regressions, not just extra work.

Watch Out for These Misconceptions

Common Misconception

During Test Suite Audit, watch for students who assume that higher coverage percentages mean better tests.

What to Teach Instead

In the Test Suite Audit, have students compare two test suites with identical coverage but different assertions. Ask them to explain why one suite is more valuable than the other based on the assertions, not the coverage number.

Common Misconception

During Test-First Challenge, students may believe that unit tests are only for large projects.

What to Teach Instead

In the Test-First Challenge, include a small class with clear edge cases (e.g., a `TemperatureConverter` with negative values). Ask students to write tests first and reflect on how these tests prevent future bugs even in a tiny class.

Common Misconception

During Think-Pair-Share, students may think testing only the happy path is sufficient.

What to Teach Instead

In Think-Pair-Share, provide a flawed test suite that only covers typical inputs. Ask pairs to brainstorm edge cases and rewrite the tests to include those scenarios, linking each case to a potential bug.

Assessment Ideas

Quick Check

After Test-First Challenge, present students with a simple class (e.g., a `BankAccount` with `deposit` and `withdraw` methods). Ask them to write two JUnit tests for the `withdraw` method: one for a valid withdrawal and one for an overdraft attempt. Assess if they follow the Arrange-Act-Assert pattern and cover both normal and error conditions.

Peer Assessment

During Test Suite Audit, have students exchange their unit test suites for a given class. Partners review the tests and answer: 'Are there at least three distinct test cases? Does each test follow AAA? Is the expected output clearly asserted?' Partners provide one written suggestion for improvement using the class’s requirements.

Exit Ticket

After Think-Pair-Share, ask students to write one sentence explaining why unit tests are important for preventing regressions and one sentence describing the main benefit of the Arrange-Act-Assert pattern. Collect responses to identify misconceptions about test purpose and structure.

Extensions & Scaffolding

• Challenge: Ask students to refactor a class from a previous unit, writing tests first to document the new behavior, then implementing the changes.
• Scaffolding: Provide a partially completed test suite with comments indicating where to insert missing test cases and assertions.
• Deeper exploration: Have students research and implement a mutation testing tool (like PIT for Java) to evaluate the effectiveness of their test suites beyond simple coverage.

Key Vocabulary

Unit Test	An automated piece of code designed to verify the behavior of a small, isolated section of a larger program, such as a single method or class.
Test Suite	A collection of unit tests grouped together to check a program's functionality. Running the suite ensures that recent changes have not broken existing code.
Arrange-Act-Assert (AAA)	A common pattern for structuring unit tests: first, set up the necessary preconditions (Arrange), then execute the code being tested (Act), and finally, verify the outcome (Assert).
Code Coverage	A metric that measures the percentage of source code that is executed by a test suite. High coverage indicates that most of the code has been tested.
Regression	A bug that appears in a program after a change has been made, causing previously working functionality to fail.