Testing checks whether a program does what you expect. Before coding, identify its inputs and outputs, then write down a few input-output pairs. Each pair is a sample test case: an input to try and the result you expect to see. section 6.1 section 2.5
Start with a result you can check
For a minutes-to-hours program, an input of 123 minutes should produce “2 hours and 3 minutes.” Also try 60 and 30 minutes. Once the program runs, compare each actual answer with the one you wrote down. section 6.1
Make testing part of the work, not just the end:
- Try varied inputs, including unusual ones. For a name-mashup program, consider short and long names and names with even or odd numbers of letters. section 12.1
- Check small pieces as you build. Print stored names after splitting them, or print a function’s returned values before adding more code. section 12.2 section 23.3
- When the result differs from what you expected, debug the code and test it again. section 36.0
For repeatable checks of individual functions, put unit tests in a separate file. Each test sets up values, calls a function, and checks its result—the Arrange, Act, Assert pattern. Write more than one test per function so different inputs have a chance to reveal mistakes. Python’s unittest library organizes these checks and reports failures. section 36.2
FAIL: test_abs_0 (__main__.TestAbs)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:/Users/Ana/test.py", line 24, in test_abs_0
self.assertEqual(absolute, 0)
AssertionError: None != 0
======================================================================
FAIL: test_prime_5 (__main__.TestPrime)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:/Users/Ana/test.py", line 7, in test_prime_5
self.assertEqual(isprime, True)
AssertionError: False != True
----------------------------------------------------------------------
Ran 6 tests in 0.000s
FAILED (failures=2)
The test output shows two useful mismatches: an absolute-value function returned None instead of 0, and a prime-checking function returned False instead of True for 5. Failed tests point to cases worth debugging. section 36.2
A practical rhythm is to think, code, test, debug, and repeat. Test a function soon after writing it; when functions work on their own, check that they work together. section 2.5 section 23.6
