|
|
|
|
|
|
|
through, but we also should output an error message when a letter other than L or P is entered. |
|
|
|
|
|
|
|
|
A standard postcondition for any program is that the user has been notified of invalid data. You should validate every input value for which any restrictions apply. A data validation If statement tests an input value and outputs an error message if the value is not acceptable. (We are validating the data when we test for negative scores in the Notices program.) The best place to validate data is immediately after it is input. In the lumberyard algorithm, we would add a data validation test to the Get Data module. |
|
|
|
|
|
|
|
|
Prompt for input
Read code, size1, size2, size3, numOrdered
Echo-print input data
IF code is not L or P
Print an error message |
|
|
|
|
|
|
|
|
|
To satisfy the data validation postcondition, the lumberyard algorithm also should test the other input values. For example, a negative size or order quantity would be invalid. More elaborate checks might test for invalid combinations of dimensions. We leave you the task of other data validations in Programming Warm-Up Exercise 12. |
|
|
|
|
|
|
|
|
Now that we've talked about testing in the problem-solving phase, we can turn to testing in the implementation phase. In this phase, you need to test at several points. |
|
|
|
|
|
|
|
|
After the code is written, you should go over it line by line to be sure that you've faithfully reproduced the top-down designa process known as a code walk-through. In a team programming situation, you ask other team members to walk through the algorithm and code with you, to double-check the design and code. |
|
|
|
|
|
|
|
|
You also should take some actual values and handcalculate what the output should be by doing an execution trace (or hand trace). When the program is executed, you can use these same values as input and check the results. |
|
|
|
|
|