Page 345 - Introduction to Programming with Java: A Problem Solving Approach

solutions. They want to avoid imposing arbitrary specifications that would cause them to miss inexpensive opportunities or incur expensive penalties. With difficult problems, people want to keep their options open.
Second, most problems have several alternate ways in which they can be solved. It takes some experi- mentation to determine the best way to solve a difficult problem. For very difficult problems, it’s impossible to know exactly “how to do it” until we have done it.
Third, when we “do it,” we must recognize it will not be perfect. There will be hidden errors. We will discover a better way to do it. The client will discover it would have been better to have asked for something different. And we’ll need to do it again.
Fourth, if we defer testing of anything complicated until the end, we are almost sure to fail. The thing might pass its one final “test,” but it will probably fail in its ultimate job, because one final test cannot catch all problems.
So, how can you deal with these difficulties?
1. Develop and maintain a sensible compromise between tight specification and flexibility.
2. Perform continuous testing at all levels. This helps you identify problems early when they are easy to fix, and it gives you objective assessment of progress. Suppose you’re in charge of a large programming project, and you ask your programmers, “How’s it coming?” You don’t want them just to say, “fine.”
You want them to show you—by running tests that demonstrate what their current code actually does.
Testing
It’s been said that, on average, experienced programmers make one mistake for every 8 or 10 lines of code. Whew! That’s a lot of mistakes. With such a high incidence of mistakes, we hope you’re properly convinced about the importance of teAstipng.ago PDF Enhancer
Testing has three aspects:
• First,subjectyourprogramtotypicalinputvalues.Ifyourprogramdoesn’tworkwith typical input values, you’re in real trouble. Co-workers and end users may question your competence if your program generates wrong answers for the typical cases.
8.5 Design Philosophy 311
3
Check most obvious things first.
• Second, subject your program to input values that are at the boundaries of accept-
ability. These boundary tests often reveal subtle problems that wouldn’t show up until later, and such problems might be much harder to fix at that time.
• Third,subjectyourprogramtoinvalidinputvalues.Inresponsetoaninvalidinputvalue,yourprogram should print a user-friendly message that identifies the problem and prompts the user to try again.
Testing is something that many people envision occurring after a product is finished. That’s an unfortunate notion, because a lone test at the end of the production of a complicated product is almost worthless. If the product fails such a test, it may be hard to determine why it failed. If the fix requires many changes, a great deal of work may have been wasted. If the product does not fail a lone final test, you may be lulled into thinking everything is OK even when it’s not. Passing a lone final test may actually be worse than failing a lone final test, because passing motivates you to release the product. It’s much more costly to fix a problem after a product has been released. (Ray knows about this!) Bottom line—Don’t wait until the end to start your testing. Test your program on a regular basis throughout the development process.
Novice programmers sometimes get the idea that it would be “unscientific” to form a pre-conception of what a test result should be before you do the test. That’s wrong. It’s important that you do have a good idea
3 Of course, we, John and Ray, never make any mistakes.☺