{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

04-testing-fnptrs - Last time 1 Tail recursion 2 Helper...

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 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: * Testing * The problem of "nearly identical" functions * Function pointer syntax * Generalization via function pointers ++++++++++++++++++++++++++++++++++++++++ Testing: Outline 1) Be skeptical! 2) End-to-end vs. incremental testing 3) The testing process Understand the spec Identify behaviors Write specific tests simple, boundary, stress Know the answers in advance or write a program to check! 4) The joy of automation +++++++++++++++++++++++++++++++++++++++++++++++++++++ **** The Testing Process We know that we need to be suspicious of our code, and we know we need to test incrementally. But, how do we test that piece of code? 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
Background image of page 1

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

View Full Document Right Arrow Icon
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. As you read a specification, 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.
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.

{[ snackBarMessage ]}