04-testing-fnptrs.student

04-testing-fnptrs.st - Last time 1 Tail recursion 2 Helper functions 3 Recursive invariants 4 Testing introduction Today we'll finish talking about

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
Last time: 1) Tail recursion 2) Helper functions 3) Recursive invariants 4) Testing introduction Today, we'll finish talking about testing, and then look at how to generalize functions by passing other functions as arguments. The outline for today is: * The testing process * The problem of "nearly identical" functions * Function pointer syntax * Generalization via function pointers **** The Testing Process To test some piece of code (either a component or a whole piece), there are several steps. 1) Understand the specification 2) Identify the required behaviors 3) Write specific tests 4) Know the answers in advance 5) Include stress tests 1) Understand the specification Before you can test something for correctness, you need to know what "correct" is. For an entire assignment, read through the spec very carefully, and make a note of everything it says you have to do. This is best done far away from a computer, in a comfy setting, with a tasty coffee or tea. If you read it carefully enough, the spec will tell you everything you need to know about "correctness". To complete most assignments, you'll have to break down the solution into constituent parts. As we'll see, it is up to you to write the specification of most of these parts, which means you are simultaneously judge and jury. This makes your job quite a bit harder, as there is no external source to tell you what is "supposed" to happen. Sometimes your program as a whole may not work correctly because your specification is incorrect (e.g. you misunderstood the definition of standard deviation). 2) Identify behaviors For each specification---of a project or a component---it is possible to boil the specification down to a list of things that must and must not happen. These are the "required behaviors" and a correct implementation must exhibit all of them. Note that a required behavior is really a "class" of behaviors. For example, a program that adds to numbers only has one behavior---that it adds numbers correctly. The list of behaviors is *not* adding 1
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
and 1 and getting 2, adding 1 and 2 and getting 3, etc. As you read the spec in step 1, it helps if you make a note of each required behavior that you find. Ex: program should print an error message and exit if payment is less than zero. 3) Write specific test cases For each of your required behaviors, write a test case (or possibly a set of test cases) that checks the set of required behaviors. To the extent possible, the test case should check *exactly* one behavior---no more! That way, if the case fails, you know where to start looking. There are two classes of test cases that make sense: * simple inputs * boundary conditions Simple cases are those that are "expected" or "normal" for the problem at hand. The test case that we gave you for project 1 is an example of a simple test case. "Boundary" cases are at the edges of what is expected, or formed to
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 01/28/2010 for the course EECS 280 taught by Professor Noble during the Winter '08 term at University of Michigan.

Page1 / 8

04-testing-fnptrs.st - Last time 1 Tail recursion 2 Helper functions 3 Recursive invariants 4 Testing introduction Today we'll finish talking about

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online