Specifications are not just comments; they are the contract that defines what a function (or module) is supposed to do and how it should be used. When we implement a function, we must write the function according to the specifications. When we call a function, we must obey the specifications, i.e., provide arguments that are valid according to the specifications.

Testing is the first step in making sure that our functions are correct--meet specifications. It is important to make a test plan--choose appropriate test cases--based on the specifications only, not based on the function code.

Lessons - watch before lecture

1. Specification Format (4 minutes)
2. Preconditions (4 minutes) A precondition is a stated assumption about an argument that is being plugged into a parameter during a function call.
3. Testing Plans (6 minutes) Testing is what we do to check that our functions are correct.
4. Test Cases (11 minutes) A test case is a pair of items: (1) the arguments to provide for a single call to a function and (2) the expected output given the arguments.

Optional reading: 4.9 and 9.5 (html version)

Lecture materials

Slides: individual slides for viewing, 6-up layout for printing
The slides files were updated after lecture; the revisions appear in orange (see slides 16, 20, 22, 26, and 27).

Examples: name_phone.py (incomplete), nametest.py, nametest2.py
To download the above .py files, right-click (Windows) or command-click (Macs) on the filename and then select "Save link as".
This way you choose where the files will be saved, instead of having your computer save to the default folder (from which you will later have to move your files for organization).

Module to support testing, for use the rest of the semester: cornellasserts.py

Lecture Recording

Solution to the post-lecture question: Did you debug function last_name_first, perhaps by adding the print statements shown on the last lecture slide? After you have done your own debugging, take a look at our solution.