lecture06 - Outline for today * Testing * Prove that...

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

View Full Document Right Arrow Icon
Outline for today * Testing * Prove that tail-recursion is a subset of iteration. **** 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 and 1 and getting 2, adding 1 and 2 and getting 3, etc. 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
Background image of page 1

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

View Full DocumentRight Arrow Icon
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. "Boundary" cases are at the edges of what is expected, or formed to exploit some detail of implementation. What might be a boundary condition for project 1? 4) Know the answers in advance. Avoid writing test cases, flinging them at the code, and quickly glancing at the output. It's too easy to fool yourself that way. Before you run a test case, write down what you expect a correct answer to be. Then, run your test case. If the result differs in *any* way from what you expected, try to figure out why. Your expectation could have been wrong, or your implementation is. Either way, there is something to fix. Doing this ABSOLUTELY REQUIRES that you understand the specification.
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 04/04/2008 for the course EECS 215 taught by Professor Phillips during the Winter '08 term at University of Michigan.

Page1 / 8

lecture06 - Outline for today * Testing * Prove that...

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