04+-+Testing+and+Function+Pointers

04+-+Testing+and+Function+Pointers - 9/1/10 Five Steps in...

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

View Full Document Right Arrow Icon
9/1/10 1 Testing and Function Pointers EECS 280 Programming and Introductory Data Structures 1 Five Steps in Testing 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 2 Five Steps in Testing 1. Understand the specification 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 Since you then have to break down the solution into its (smaller) constituent parts, you must write most of those specifications. 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). 3 Five Steps in Testing 2. Identify the required behaviors For any specification, 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 two numbers only has one behavior – add the numbers correctly. The list of behaviors is not adding 1 and 1 and getting 2, adding 1 and 2 and getting 3, etc… Try this for project 1. For example, what happens if a payment is less than 0? 4 Five Steps in Testing 3. Write specific tests For each of your required behaviors, write one or more test cases that check them. 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. 5 Five Steps in Testing 3. Write specific tests There are three classes of test cases that make sense: Simple inputs Boundary conditions Nonsense 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. “Nonsense” cases are those that are clearly unexpected. What are examples of these cases for project 1? 6
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/1/10 2 Five Steps in Testing 4. Know the answers in advance Instead of quickly running test cases and glancing at the output: Write down what you expect a correct answer to be first.
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 02/14/2012 for the course EECS 280 taught by Professor Noble during the Winter '08 term at University of Michigan.

Page1 / 5

04+-+Testing+and+Function+Pointers - 9/1/10 Five Steps in...

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