AP CSP Create Task, Page 4

Testing Your Project

On this page, you will reflect on your specifications to design a testing plan, and then you'll run the tests and fix any errors.

CRD-2.J.1, CRD-2.J.2, CRD-2.J.3

After you develop a prototype, you'll need to test it and revise it based on the results. But testing is more than "just playing with the program as a user." Good testing is systematic (it follows a system). It also requires referring back to the program specifications you wrote to identify a variety of inputs that will test different possibilities for user behavior (including extreme cases, such as very long words, very small numbers, very fast clicks, etc.) and to identify the expected outcomes for these inputs.

CRD-2.J

Looking back at your specifications, identify: the types of inputs your program takes, a variety of different and extreme cases for these inputs, and the expected outcomes for each case. Record your plan for the testing inputs and their expected outcomes.

What you'll need to do to fix errors in your program depends on what type of error occurs.

CRD-2.I.1, CRD-2.I.2, CRD-2.I.3, CRD-2.I.4

A logic error causes the program to produce the wrong output. (This is the most common error in Snap!)
A syntax error means the rules of the programming language were not followed. (These are more common in text-based languages because you can easily mistype something or forget a needed semi-colon or quotation mark. By comparison, Snap! doesn't let you drop a block where it doesn't belong, so this is less likely in Snap!)
A run-time error is an error that happens while your program is running. What counts as a run-time error depends on the programming environment you are using. In Snap!, these are the errors that stop your program with a red halo surrounding the block that caused the error. For example:
An overflow error happens when a number is too extreme for the computer to handle (too big or too small).

CRD-2.I.5

There are many ways to find and correct errors. Here are several common ones:

Test Cases—identifying extreme input cases to test and identifying their expected outcomes (This is the primary method you'll be using.)
Hand tracing—reading the code by hand and testing various cases as though you were the computer
Visualizations—creating a visual way to see what your program is doing (such as a variable watcher or a chart that shows inputs, expected outcomes, and actual outcomes)

You learned about Visible Stepping on Unit 1 Lab 3 Page 1: Exploring Motion.

Debuggers—some programming languages include a debugging feature that will help you locate and understand errors (such as Visible Stepping in Snap!)
Adding Output(s)—you can add say blocks to your code or add temporary variable watchers to help you understand what values are held by your program at different times (this is another great strategy in Snap!)

You learned other techniques for debugging on Unit 3 Lab 1 Page 6: Debugging Recap.

CRD-2.I parts a and b

Test for errors in your program. Try out the inputs you have selected and record their outcomes. Were there any discrepancies between what you expected and what happened? Resolve any problems and test again.