Computer Science · 11th Grade

Active learning ideas

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.

• Common Core State Standards
• CSTA: 3B-AP-16

• 20–45 min
• Pairs → Whole Class
• 3 activities

Activity 01

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

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.

What to look for

Present students with a simple Java class (e.g., a `Calculator` with `add` and `subtract` methods). Ask them to write two JUnit tests for the `add` method: one for positive numbers and one for a positive and a negative number. Check if they correctly implement the Arrange-Act-Assert pattern.

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

Activity 02

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

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.

What to look for

Students exchange the unit test suites they designed for a given class. Each student reviews their partner's tests, answering: 'Are there at least three distinct test cases? Does each test follow AAA? Is the expected output clearly asserted?' Partners provide one suggestion for improvement.

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

Activity 03

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

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.

What to look for

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.

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

A few notes on teaching this unit

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.

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

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

  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.

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

  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.

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

  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.

---

Methods used in this brief

• Project-Based Learning
• Think-Pair-Share