Testing Functions with Inputs

For 9th graders, testing functions with inputs moves beyond fixing errors to building confidence in code before it runs. Active learning works here because students must design inputs, predict outputs, and confront their own assumptions about how code should behave.

• 9th Grade
• Computer Science
• 4 activities
• 20 min–40 min

Learning Objectives

1. Design a comprehensive set of test cases for a given function, including typical, edge, and invalid inputs.
2. Evaluate the effectiveness of a function's output against a defined set of expected results for various inputs.
3. Identify common programming errors, such as off-by-one errors or incorrect handling of zero, by analyzing function test results.
4. Explain the importance of proactive testing in preventing software defects and ensuring code reliability.

Problem-Based Learning

⏱ 40 min·Pairs

Test Case Design Workshop

Each student writes a function and then designs a test suite with at least six cases: two typical inputs, two boundary values, and two invalid inputs. They trade functions with a partner, who runs the test suite and reports which cases passed and which failed, with notes on what the failure revealed.

Prepare & details

Explain the importance of testing functions with different inputs.

Facilitation Tip: During Test Case Design Workshop, have students work in pairs to write test cases for a function you provide first, then for each other's functions to model the peer review process.

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

Think-Pair-Share

⏱ 20 min·Pairs

Think-Pair-Share: What Could Go Wrong?

Present three function descriptions without code. Students individually list at least four inputs that could cause problems, then compare lists with a partner and categorize inputs by type (valid typical, valid edge, invalid). The class discusses which categories are most often overlooked.

Prepare & details

Design a set of test cases for a given function.

Facilitation Tip: In Think-Pair-Share: What Could Go Wrong?, assign roles so one student explains potential issues while the other records test cases, then switch roles to deepen perspective-taking.

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

Problem-Based Learning

⏱ 30 min·Pairs

Bug Hunt: Failing Tests

Provide pairs with a function and a set of test cases, some of which fail. They must identify the input pattern that causes failure and trace through the code to find the bug, without modifying the tests. They document their findings as a structured bug report.

Prepare & details

Identify common errors that can be found by thoroughly testing function inputs and outputs.

Facilitation Tip: For Bug Hunt: Failing Tests, provide intentionally buggy code and broken test cases so students must debug both the function and the test logic to see how tests guide corrections.

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

Gallery Walk

⏱ 30 min·Small Groups

Gallery Walk: Test Coverage Analysis

Post four functions with their test suites. Students annotate which inputs are missing from each test suite, writing specific test cases that should be added. The class votes on the most critical missing test for each function and discusses why that case matters.

Prepare & details

Explain the importance of testing functions with different inputs.

Setup: Wall space or tables arranged around room perimeter

Materials: Large paper/poster boards, Markers, Sticky notes for feedback

• Understand
• Apply
• Analyze
• Create
• Relationship Skills
• Social Awareness

Teaching This Topic

Start with small, relatable functions so students focus on testing strategy rather than complexity. Use public debugging sessions where you model thinking aloud about which inputs to test and why. Avoid rushing to fix bugs; instead, emphasize that tests should expose errors before code reaches users. Research shows that students who practice testing early develop stronger debugging habits that transfer to larger projects.

What to Expect

Students will create test cases for functions, identify edge cases, and recognize that a single passing test does not guarantee correctness. Successful learning is visible when students explain why certain inputs reveal bugs and adjust their testing strategies accordingly.

Watch Out for These Misconceptions

Common Misconception

During Test Case Design Workshop, some students may think that testing a few obvious inputs is enough.

What to Teach Instead

Use the workshop to push students to include edge cases and invalid inputs, then have them swap test suites with peers to challenge each other's assumptions about sufficient coverage.

Common Misconception

During Think-Pair-Share: What Could Go Wrong?, students may assume their partner's function is flawless.

What to Teach Instead

Ask students to intentionally brainstorm ways their partner's function could fail, then write test cases for those scenarios to reveal gaps in their own expectations.

Common Misconception

During Bug Hunt: Failing Tests, students may believe the test case is correct and the function is broken when the opposite is true.

What to Teach Instead

Have students justify each test case's expected output before running it, then compare their reasoning to the function's actual behavior to identify whether the bug lies in the test or the code.

Assessment Ideas

Peer Assessment

After Test Case Design Workshop, have students exchange functions and test suites with peers. Each student runs their partner's tests, records discrepancies, and discusses whether the tests expose meaningful bugs or miss critical cases.

Quick Check

During Think-Pair-Share: What Could Go Wrong?, circulate and ask pairs to share one edge case they identified and explain why it matters for the function's correctness.

Exit Ticket

After Bug Hunt: Failing Tests, give students a function with a subtle bug and ask them to write one test case that exposes it, explaining why that input causes the function to fail in their own words.

Extensions & Scaffolding

• Challenge: Ask students to design a function with hidden edge cases and a corresponding set of test cases that would reveal those cases.
• Scaffolding: Provide a partially completed test table with inputs filled in but expected outputs and actual outputs blank for students to complete.
• Deeper exploration: Introduce property-based testing, where students generate inputs randomly to check if a function maintains a property (e.g., output is always positive) for many cases.

Key Vocabulary

Test Case	A specific set of inputs and expected outputs designed to verify a particular aspect of a function's behavior.
Typical Input	A value that is commonly expected and within the normal operating range for a function.
Edge Case	An input value that lies at the boundary of valid inputs, often representing extreme or unusual conditions.
Invalid Input	A value that is outside the acceptable range or type for a function, which the function should ideally handle gracefully.
Assertion	A statement in code that checks if a condition is true; if false, it indicates a failure in the function's logic during testing.