Testing Formula

The Formula

\text{test passes} \iff o_e = o_a

When to use: Try to break it before users do. Test normal cases, edge cases, and error cases.

Quick Example

Test divide function with: (10, 2), (0, 5), (-6, 3), (5, 0) [error case].

What This Formula Means

Systematically running a program with known inputs to verify that its outputs are correct. Testing involves designing test cases that cover normal inputs, boundary values, and error conditions, then comparing actual results against expected results.

Try to break it before users do. Test normal cases, edge cases, and error cases.

Formal View

A test case is a triple (i, o_e, o_a) where i is the input, o_e is the expected output, and o_a is the actual output. The test passes iff o_e = o_a. A test suite \{T_1, T_2, \ldots, T_m\} aims to cover all execution paths.

Worked Examples

Example 1

easy
A function isEven(n) should return TRUE if n is even and FALSE otherwise. Suggest three test cases, including a normal, boundary, and erroneous value.

Solution

  1. 1
    Step 1: Normal test: isEven(4) should return TRUE. This tests typical valid input.
  2. 2
    Step 2: Boundary test: isEven(0) should return TRUE. Zero is an edge case that is technically even.
  3. 3
    Step 3: Erroneous test: isEven('hello') should handle the invalid input gracefully (return an error or FALSE). This tests that the function does not crash on bad input.

Answer

Normal: isEven(4) → TRUE. Boundary: isEven(0) → TRUE. Erroneous: isEven('hello') → error/FALSE.
Good testing uses normal data (typical valid input), boundary data (edge cases at limits), and erroneous data (invalid input). This ensures the program works correctly in all situations.

Example 2

medium
A program grades students: 90-100 = A, 80-89 = B, 70-79 = C, 60-69 = D, below 60 = F. Design a complete set of test data including boundary values.

Common Mistakes

  • Only testing the happy path (normal inputs) and neglecting edge cases and error conditions
  • Writing tests that depend on each other's execution order instead of being independent
  • Assuming that passing all tests means the program is bug-free—testing can only show the presence of bugs, not their absence

Common Mistakes Guide

If this formula feels simple in isolation but keeps breaking during real problems, review the most common errors before you practice again.

Algorithm MistakesDebugging Mistakes

Why This Formula Matters

Quality software requires thorough, systematic testing because bugs found early cost far less to fix. Professional software teams typically write more test code than production code, and automated testing catches regressions before they reach users.

Frequently Asked Questions

What is the Testing formula?

Systematically running a program with known inputs to verify that its outputs are correct. Testing involves designing test cases that cover normal inputs, boundary values, and error conditions, then comparing actual results against expected results.

How do you use the Testing formula?

Try to break it before users do. Test normal cases, edge cases, and error cases.

Why is the Testing formula important in CS Thinking?

Quality software requires thorough, systematic testing because bugs found early cost far less to fix. Professional software teams typically write more test code than production code, and automated testing catches regressions before they reach users.

What do students get wrong about Testing?

Test edge cases: empty input, zero, maximum values, unexpected types.

What should I learn before the Testing formula?

Before studying the Testing formula, you should understand: algorithm, debugging.

← Back to Testing See All Examples Common Mistakes Practice Problems