04+-+Testing+and+Function+Pointers - 9/20/2009 Five Steps...

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

View Full Document Right Arrow Icon
9/20/2009 1 Testing and Function Pointers EECS 280 Programming and Introductory Data Structures Five Steps in Testing c To test some piece of code (either a component or a whole piece): 1. Understand the specification 2. Identify the required behaviors 3. Write specific tests 4. Know the answers in advance 5. Include stress tests Five Steps in Testing 1. Understand the specification c For an entire assignment, read through the specification very carefully, and make a note of everything it says you have to do – and stay away from the computer c Since you then have to break down the solution into its (smaller) constituent parts, you must write most of those specifications. c This makes your job quite a bit harder, as there is no external source to tell you what is “supposed” to happen. c Sometimes your program as a whole may not work correctly because your specification is incorrect (e.g. you misunderstood the definition of standard deviation). Five Steps in Testing 2. Identify the required behaviors c For any specification, it is possible to boil the specification down to a list of things that must and must not happen. c These are the “required behaviors” and a correct implementation must exhibit all of them . c Note that a required behavior is really a “class” of behaviors. c For example, a program that adds two numbers only has one behavior – add the numbers correctly. c The list of behaviors is not adding 1 and 1 and getting 2, adding 1 and 2 and getting 3, etc… c Try this for project 1. For example, what happens if a payment is less than 0? Five Steps in Testing 3. Write specific tests c For each of your required behaviors, write one or more test cases that check them. c To the extent possible, the test case should check exactly one behavior – no more! c That way, if the case fails, you know where to start looking. Five Steps in Testing 3. Write specific tests c There are three classes of test cases that make sense: c Simple inputs c Boundary conditions c Nonsense c Simple cases are those that are “expected” or “normal” for the problem at hand. c “Boundary” cases are at the edges of what is expected, or formed to exploit some detail of implementation. c “Nonsense” cases are those that are clearly unexpected. c What are examples of these cases for project 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
9/20/2009 2 Five Steps in Testing 4. Know the answers in advance c Instead of quickly running test cases and glancing at the output: c Write down what you expect a correct answer to be first. c If the result differs in any way from what you expected, try to figure out why.
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 10/26/2010 for the course EECS 280 taught by Professor Noble during the Fall '08 term at University of Michigan.

Page1 / 5

04+-+Testing+and+Function+Pointers - 9/20/2009 Five Steps...

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