DOC PREVIEW
UMD CMSC 132 - Program Testing

This preview shows page 1-2-3-4-5-6 out of 19 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 19 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CMSC 132: Object-Oriented Programming IIProgram TestingDepartment of Computer ScienceUniversity of Maryland, College ParkProgram TestingEmpirical testingTest software with selected test casesMore scalable than verificationTest failures frequently indicate software errorsAbsence of failures doesn’t prove software correctIf code isn’t exercised by any test, hard to have confidence in itEven if it has been “formally verified”Kinds of testingAutomated testingThe software is tested by a completely automatic processe.g., jUnit or submit server testingCan be expensive or difficult to construct, but fairly cheap to repeatManual testingA person uses the software, perhaps guided by a script, and notes bugsOften easier to conduct than writing test cases, but very expensive to repeatTest sizeSmallUnit test – test individual componentsMediumIntegration testsTest subsystems containing several componentsCan test interactions between components, properties that are only demonstrated in larger systemsLargeSystem or acceptance testsTest entire system, including non-software componentsTypes of TestingClear box testingAllowed to examine codeAttempt to improve thoroughness of testsBlack box testingNo knowledge of codeTreat program as “black box”Test behavior in response to inputsTesting – TerminologyTest caseIndividual testTest suiteCollection of test casesTest harnessProgram that executes a series of test casesTest frameworkSoftware that facilitates writing & running testsExample – JUnitTesting – TerminologyTest driverProgram to create environment for running testsDeclares variables, creates objects, assigns valuesInvokes tested code, checks results, reports failuresStubSkeleton code in place of unfinished method / classImplements minimal functionality to allow test to occurAllows software testing to beginMock ObjectsSimilar to a stubBut they record the calls made to themIf the wrong calls are made to them, the test failsCan prerecord the sequence of expected callsAlso eliminates need for mock objects to contain any logicOr the test driver can query the calls after the testUseful if calls aren’t deterministic and need more careful logic to checkWhen to use mock objectsIf you want to test the calls made to other objects, rather than the return values or output of the methods under testYou need to use mock objectsMock objects can also be easier to use than creating functional stubsMock objects can simulate situations that might be hard to test on real codee.g., does the code recover if the network fails?EasyMock examplewarehouseControl = MockControl.createControl(Warehouse.class);warehouseMock = (Warehouse) warehouseControl.getMock(); Order order = new Order(TALISKER, 50);//setup – record expected calls and return valueswarehouseMock.hasInventory(TALISKER, 50); warehouseControl.setReturnValue(true);warehouseMock.remove(TALISKER, 50);warehouseControl.replay(); // put mock into replay mode//exercise – execute code under test order.fill(warehouseMock); //verify warehouseControl.verify(); assertTrue(order.isFilled());Unit TestTest individual units extensivelyClassesMethodsCentral part of Extreme Programming (XP)Extensive unit testing during developmentPair programmingDesign unit tests along with specificationApproachTest each method of classTest every possible flow path through methodTest CoverageHow do you know if your tests are any good?In general, you can know if they are bad or insufficient, harder to tell that they are goodDo they handle and check all the situations described in the specification and use cases?Do they invoke all the methods?Do they test all of the code?Flow PathUnique execution sequence through programExample S1while (B1) {if (B2)S2elseS3}FlowsS1S1, S2S1, S3S1, S2, S2S1, S2, S3S1, S3, S2S1, S3, S3…Test CoverageNot possible to test all flow pathsMany paths by combining conditionals, switchesInfinite number of paths for loopsNew paths caused by exceptionsTest coverageWhether code is executed by some test caseAlternative to flow pathEnsure high % (if not all) of lines of code testedDoes not capture all possible flow pathsEven if all lines of code tested by some test caseTest Coverage, continuedBranch coverage is strong than statement coverageGenerally achievableCan be tricky to cover all exceptions and error casesControl flow coverage doesn’t tell you about data coverageDid you try it with negative integers, or with non-ASCII characters?Coverage won’t tell you about functionality you forgot to implement or testWhen to testIf code has never been tested, you have no idea if it ever workedBut it is also important to perform regression testingCheck to see if some functionality that used to work stops workingThe faster a regression is identified, the cheaper it is to fix, at any scaleWithin a minute is better than within an hourWithin a day is better than within a weekWhy regression test?Bits don’t rotBut running regression tests give developer much more freedom to change existing code“I need to rewrite this component to support new functionality – I wonder if anything might be depending on the details of how it works now?”This freedom is key to agile development, and important even in more structured development methodologiesSelecting regression testsBig, well tested systems will have too many tests to run all of them every time you compilePrioritize tests by sizeOnes that take only a few secondsOnes that need to run over the weekendAnd by proximity to code changedAfter changing some code, you only need to rerun the tests that executed the code that was changedResearch work on prioritizing testsDeveloping Quality Test CasesUseful to have someone else write test casesOne person might make the same incorrect assumption in both their code and in their testsTips on developing test casesDevelop test data during analysis & design phasesUse cases  Test casesPay close attention to problem specificationCheck boundary conditions 1stand last iterations of loop1stand last values added to data structureImprove code


View Full Document

UMD CMSC 132 - Program Testing

Documents in this Course
Notes

Notes

8 pages

Recursion

Recursion

12 pages

Sorting

Sorting

31 pages

HTML

HTML

7 pages

Trees

Trees

19 pages

HTML

HTML

18 pages

Trees

Trees

19 pages

Honors

Honors

19 pages

Lecture 1

Lecture 1

11 pages

Quiz #3

Quiz #3

2 pages

Hashing

Hashing

21 pages

Load more
Download Program Testing
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Program Testing and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Program Testing 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?