Lecter Java: Program design - Chapter 13: Testing and Debugging

Testing and DebuggingTesting FundamentalsTest as you developEasier to find bugs early rather than laterPrototyping helps identify problems earlyCategories of bugssoftware crashes or data corruptionfailure to meet or satisfy the specificationpoor or unacceptable performancehard or difficult to useTesting fundamentalsImpossible to test a program completelyThree distinct paths through the programIf the loop executes 20 times, there are 320 different sequences of executionsReviews and inspectionsInspectionsFormal process of reviewing codeFirst employed by IBM in 1976Early work showed that design and review inspections remove 60 percent of the bugs in a productReviews and inspectionsRoles of participantsModeratorRuns the inspectionEnsure that the process moves alongReferees the discussionEnsures action items doneInspectorSomeone other than authorSome interest in the codeCarefully review code before inspection meetingAuthorMinor roleMay answer questions about codeReviews and inspectionsRoles of participantsScribeRecord all errors detectedKeep list of action itemsReviews and inspectionsInspection processPlanningCode to review chosenModerator assigns taskChecklists createdModerator assigns a presenter (usually one of the inspectors)OverviewAuthor describes high-level aspects of project that affected the design or codeSometimes skipped (if all participants are knowledgeable)Reviews and inspectionsInspection processPreparationWorking alone, each inspector reviews code noting problems or questionsShouldn’t take more than a couple of hoursInspection meetingPresenter walks through the codeProblems are discussedScribe records all errors and action itemsErrors are not fixed at this timeInspection report Moderator prepares a written reportBlack-box and white-box testingWhite-box testing indicates that we can “see” or examine the code as we develop test casesBlock-box testing indicates that we cannot examine the code as we devise test casesSeeing the code can bias the test cases we createForces testers to use specification rather than the codeComplementary techniquesBlack-box and white-box testingTest boundary conditionspublic static int binarySearch(char[] data, char key) { int left = 0; int right = data.length - 1; while (left 12)) { System.output.println("Bad request: " + year + " " + month); return;}Black-box and white-box testingSuggests the following boundary testsInput YearInput Month158221583015831315831158312Black-box and white-box testingPath coverage or path testing—create test cases that causes each edge of the program’s controlflow graph to be executedExampleif (x != y) { y = 5;}else { z = z - z;}if (x > 1) { z = z / x;}else { z = 0;}if (x != 3)y = 5z = z - xif (x != 3)y = 5y = 5Black-box and white-box testingTesting tipsTest earlyUse inspectionsTest boundariesTest exceptional conditionsMake testing easily repeatableIntegration and system testingIntegration testing is done as modules or components are assembled.Attempts to ensure that pieces work together correctlyTest interfaces between modulesSystem testing occurs when the whole system is put togetherDebuggingUse the scientific methodGather dataDevelop a hypothesisPerform experimentsPredict new factsPerform experimentsProve or disprove hypothesisDebuggingTips and techniquesSimplify the problemStabilize the errorLocate the errorExplain the bug to someone elseRecognize common bugsOversubscriptingDereferencing nullRecompile everythingGather more informationPay attention to compiler warningsFix bugs as you find themTake a break