1 / 56

8. UNIT TESTING

8. UNIT TESTING. Software Engineering Roadmap: Chapter 8 Focus. Identify corporate practices. Test units (parts) separately - use implementations - apply discipline - gain coverage. Plan project. Maintain. Analyze requirements. Integrate & test system. Design.

tituse
Télécharger la présentation

8. UNIT TESTING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 8. UNIT TESTING

  2. Software Engineering Roadmap: Chapter 8 Focus Identify corporate practices Test units (parts) separately - use implementations - apply discipline - gain coverage Plan project Maintain Analyze requirements Integrate & test system Design Test units Implement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  3. Learning Goals of This Chapter • Understand meaning of unit testing • Distinguish black box vs. white box testing • Attain proper test coverage • Learn a testing standard • Inspect a unit test plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. 1. Introduction to unit testing

  5. Golden Rules of Testing Goal of testing: maximize the number and severity of defects found per dollar spent • thus: test early

  6. Golden Rules of Testing Goal of testing: maximize the number and severity of defects found per dollar spent • thus: test early Limits of testing: Testing can only determine the presence of defects, never their absence • use proofs of correctness to establish “absence” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  7. Testing: the Big Picture 3. System tests 2. Integration tests Module combination 1. Unit tests Module Function

  8. Testing: the Big Picture 3. System tests Include use-cases 2. Integration tests OO: Packages of classes Module combination 1. Unit tests Combinations of methods in class Module Methods Function

  9. Unified Process Jacobson et al: USDP Requirements Analysis Design Implemen- tation Test Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k …..

  10. Unified Process Jacobson et al: USDP Requirements Analysis Design Implemen- tation Test Inception Elaboration Construction Transition Unit Tests Integration tests ... System tests Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k ….. …..

  11. RoadMap for Unit Testing Requirements 1. Plan for unit testing -- see section SSS Detailed design . . . . Test results

  12. RoadMap for Unit Testing Requirements 1. Plan for unit testing -- see section SSS Identify largest trouble spots Detailed design Unit test plan 2. Acquire test set -- see section SSS Products of prior testing Test set 3. Execute unit test -- see section SSS Test results Code under test IEEE, 1986

  13. 2. Test types

  14. Black-, Gray-, & White-box Testing Input determined by... Result Actual output compared with required Black box … requirements* * from previous phase

  15. Input determined by... Black-, Gray-, & White-box Testing Result Actual output compared with required output Black box … requirements Gray box As for black- and white box testing … requirements & key design elements White box Confirmation of expected behavior …design elements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  16. Test Input Possibilities Infinitely many illegal values: choose a finite sample. principal $100 $100M 20% Infinitely many legal values: choose a finite sample. inflation estimate 25% interest rate 1% 0% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  17. Test Input Partitioning and Boundaries An illegal region principal Boundaries $100 $100M 20% inflation estimate Range of valid inputs 25% interest rate 1% 0% Equivalence partitions Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  18. Testing Ranges: Elementary Cases 1. within range 2. at the boundaries of the range 3. outside the range (“illegal”) range Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  19. Covering Every Statement is Not Sufficient (Myers) Required program u>1 and v==0 Yes x = x/u No u==2 or x>0 Yes ++x No

  20. Covering Every Statement is Not Sufficient (Myers) • Code attempt to implement flowchart • if( (u>1) && (v==0) ) (1) • x = x/u; (2) • if( (u==2) || (x>3) ) (3) • ++x; (4) • u=2, v=0 and x=3 • executes every line (1) - (4) • gives the correct output x= 2.5 • However, line (3) is wrong Required program u>1 and v==0 Yes x = x/u No u==2 or x>0 Yes ++x No

  21. Paths to be Checked Parameter & settings make sense? N Y Set _name to “defaultName" Parameter name too long? N Y Set _name to parameter Truncate name

  22. Paths to be Checked Parameter & settings make sense? N Y Set _name to “defaultName" Parameter name too long? N Y Decision Coverage Set _name to parameter Truncate name Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. Assertion-based testing for max() 1/2 public static boolean checkAssertion ( int loopSoFarP, int indexOfMaxP, double[] arrayP ) { // First establish following booleans: boolean b1M = true;/* means values of arrayP[ ] are lower than arrayP[ indexOfMaxP ] for all indices < indexOfMaxP */ if( indexOfMaxP != 0 )// b1M true if max so far is first element for( int u = 0; u < indexOfMaxP; ++u ) b1M &= ( arrayP[u] < arrayP[ indexOfMaxP ] ); . . . . Defining the assertion checker

  24. Assertion-based Testing for max() public static boolean checkAssertion ( int loopSoFarP, int indexOfMaxP, double[] arrayP ) { // First establish following booleans: boolean b1M = true;/* means values of arrayP[ ] are lower than arrayP[ indexOfMaxP ] for all indices < indexOfMaxP */ if( indexOfMaxP != 0 )// b1M true if max so far is first element for( int u = 0; u < indexOfMaxP; ++u ) b1M &= ( arrayP[u] < arrayP[ indexOfMaxP ] ); boolean b2M = true;/* means vals. of arrayP[ ] no higher than arrayP[ indexOfMaxP ] for indices indexOfMaxP … loopSoFarP */ for( int v = indexOfMaxP; v <= loopSoFarP; ++v ) b2M &= ( arrayP[v] <= arrayP[ indexOfMaxP ] ); Defining an Assertion Checker: 1 of 2: Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  25. Defining an Assertion Checker for max(): 2 of 2 if ( // Loop has progressed up to index loopSoFarP ( 0 <= loopSoFarP ) && (loopSoFarP < arrayP.length ) && // indexOfMaxP is the index <= loopSoFarP ... ( 0 <= indexOfMaxP ) && ( indexOfMaxP <= loopSoFarP ) && b1M && b2M // ... where the first max occurs ) { System.out.println( "Assertion valid" ); return true; } else { System.out.println( "Assertion invalid" ); return false; } } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  26. Applying Assertion-basedtesting to max() • /** Finds index & value of first of the largest array elements ... */ • public static void main( String[] mainArg ) • { • double[] a = getArray(); • // Let I be the assertion … (see section tbd of chapter 7) ... Establish I • int i = 0; • int k = 0; • boolean validityM = checkAssertion( i, k, a );// assertion test • // Following preserves I .… terminates .… (section tbd of chapter 7) • while( i != a.length - 1 ) • { ++i; • if( a[i] > a[k] ) • k = i; • validityM = validityM && checkAssertion( i, k, a ); // assertion test • } • System.out.println( "First max value is " + a[k] + " at index " + k ); • System.out.println( "Validity: " + validityM );// assertion report • } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  27. 3. Planning unit tests

  28. Plan for Unit Testing One way to ... 1. Decide on the philosophy for unit testing • individual engineer responsible (common)? • reviewed by others? • designed & performed by others? 2. Decide what / where / how to document • individual’s personal document set (common)? • how / when to incorporate into other types of testing? • incorporate in formal documents? • use tools / test utilities? 3. Determine extent of unit testing (i.e., in advance). • do not just “test until time expires” • prioritize, so that important tests definitely performed 4. Decide how and where to get the test input • see section tbd. 5. Estimate the resources required • use historical data if available 6. Arrange to track time, defect count, type & source Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  29. 4. Checklists and examples for method testing

  30. Perform Method Testing (Humphrey) 1/2 One way to ... 1. Verify operation at normal parameter values (a black box test based on the unit’s requirements) 2. Verify operation at limit parameter values (black box) 3. Verify operation outside parameter values (black box) 4. Ensure that all instructions execute (statement coverage) 5. Check all paths, including both sides of all branches (decision coverage) 6. Check the use of all called objects 7. Verify the handling of all data structures 8. Verify the handling of all files Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  31. Perform Method Testing (Humphrey) 2/2 One way to ... 9. Check normal termination of all loops (part of a correctness proof) 10. Check abnormal termination of all loops 11. Check normal termination of all recursions 12. Check abnormal termination of all recursions 13. Verify the handling of all error conditions 14. Check timing and synchronization 15. Verify all hardware dependencies Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  32. 4. Checklists and examples for method testing

  33. Relating Tests to Requirements & Design (2) Design GameCharacter Requirements An abstract class with attribute name ... (1) D-Requirements 3.2.EC.1.2 Qualities of Encounter characters Every game character has the same set of qualities. Each quality shall be a non-negative floating point number with at least one decimal of precision. . . . . . . .

  34. Relating Tests to Requirements & Design (2) Design GameCharacter Requirements An abstract class with attribute name ... (1) D-Requirements 3.2.EC.1.2 Qualities of Encounter characters Every game character has the same set of qualities. Each quality shall be a non-negative floating point number with at least one decimal of precision. . . . Test this class ... ... against this requirement Characters GameCharacter Test this method ... Encounter Characters ... against this requirement EncounterCharacter adjustQuality() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  35. Unit test Applied to ... Concentration Stamina Results in a zero value? 1. Within range No: Test 1.1 Test 1.1.1 etc. Yes: Test 1.2 Test 1.2.1 etc. Partitioning of Range for Unit Testing 1 of 2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  36. Unit test Applied to ... Concentration Stamina Results in a zero value? 2. Outside range No: Test 2.1 Test 2.1.1 etc. Yes: Test 2.2 Test 2.2.1 etc. Partitioning of Range for Unit Testing 2 of 2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  37. 5. Checklists and examples for class testing

  38. Perform ClassUnit Tests One way to ... 1. Exercise methods in combination • 2-5, usually • choose most common sequences first • include sequences likely to cause defects • requires hand-computing the resulting attribute values 2. Focus unit tests on each attribute • initialize, then execute method sequences that affect it 3. Verify that each class invariant is unchanged • verify that the invariant is true with initial values • execute a sequence (e.g., the same as in 1.) • verify that the invariant still true 4. Verify that objects transition among expected states • plan the state / transition event sequence • set up the object in the initial state by setting variables • provide first event & check that transition occurred . etc. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  39. Encounter State-Transition Test Sequence 1 of 2 test step 1 Preparing Verify that the game is initially in Preparing state (by checking on the class membership of gameStateI) Player dismisses qualities menu Waiting

  40. Encounter State-Transition Test Sequence 1 of 2 test step 1 test step 2 Preparing Verify that the game is initially in Preparing state (by checking on the class membership of gameStateI) Dismiss the quality menu, and verify that the game is in Waiting state. Player dismisses qualities menu test step 3 Move the player character to an adjacent area, and verify that the game is still in Waiting state. Waiting Move to adjacent area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  41. Complete Encounter State-Transition Test 1 2 Preparing Player dismisses qualities menu Reporting Player dismisses encounter report menu 6 3 5 Waiting Encounter completed Move to adjacent area 4 Character enters area inhabited by an opponent Engaging Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  42. 6. Summary

  43. Unit Testing: Summary • Unit testing =  “pieces” • Other testing =  “assemblies” • Black box: input / output only • White box: verifies processing • Several ways • Ensure completeness • Test planning earlier / better • helps clarify requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  44. Case StudyEncounterCharacter.java

  45. Listing page 1 /** To test this class. * @param argsP destination of method test log, class test log respectively */ public static void main( String[] argsP ) { // Default files on which to write test output & run tests String methodOutputFileNameM = "methodOutput.txt"; String classOutputFileNameM= "classOutput.txt"; if( argsP != null && argsP.length == 2 ) // use defaults if input improper { methodOutputFileNameM = argsP[0]; classOutputFileNameM = argsP[1]; } // 1. EXECUTE TESTS WHICH DO NOT REQUIRE HUMAN INTERVENTION // Test methods individually, then test class try { testEncounterCharacterMethods( methodOutputFileNameM ); testEncounterCharacterClass( classOutputFileNameM ); } catch( IOException eP ) { System.out.println( eP ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  46. // 2. EXECUTE TESTS WHICH DO REQUIRE HUMAN INTERVENTION Frame[] imageTests = { // Display test cases. new testCharacterImage( // Missing image. new EncounterCharacter( "GuyWithNoImage", null ) ), new testCharacterImage( // Image is present. new EncounterCharacter( "Elena", "elena.gif" ) ) }; for( int i = 0; i < imageTests.length; i++) { // Display each test window. imageTests[i].setSize(400, 250); // Adequate size for character. imageTests[i].setVisible(true); imageTests[i].show(); } try { // Let user examine windows. Thread.currentThread().sleep( 30*1000 ); } catch( Exception exc ) { } for( int i = 0; i < imageTests.length; i++ ) // Shut the windows. imageTests[i].dispose(); System.exit( 0 ); } Listing page 2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  47. /** Tests this class by executing its methods in combination. * @param destinationP Location to write results. * @exception IOException If there’s a problem opening or accessing destinationP */ public static void testEncounterCharacterClass( String destinationP ) throws IOException { /* Prepare for the test */ PrintWriter outM = new PrintWriter( new FileOutputStream( destinationP ) ); System.out.println( "\nEncounterCharacter class test results on " + destinationP + "\n" ); /* * The following methods will be tested in sequences: * * a. adjustQuality( String qualityP, float qualityValueP ) * d. deleteFromEncounterCharacters( EncounterCharacter encounterCharacterP ) * ge. EncounterCharacter getEncounterCharacter( String nameP ) * gq. float getQualityValue( String qualityP ) * gt. float getTolerance() * io. int indexOf( String qualityP ) * ii. insertIntoEncounterCharacters( EncounterCharacter encounterCharacterP ) * m. int maxNumCharsInName() * sq. setQuality( String qualityP, float qualityValueP ) * so. float sumOfQualities() Listing page 3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  48. Listing page 4 * * The following sequences occur commonly: * ge-aq-so * ge-sq-a-gq * . . . . . * The following sequences have a high potential for defects: * ge-aq-aq-gq-so * . . . . . */ /* Test C1: ge-aq-so */ EncounterCharacter eC1M = new EncounterCharacter( "CharForTestC1" ); // method “ge” eC1M.adjustQuality(QUAL_STRENGTH, 40.0f ); // aq TestExecution.printReportToFile( outM, "Class test ge-aq-so", eC1M.sumOfQualities(), 100.0f ); // so /* Test C2: ge-aq-aq-gq-so */ EncounterCharacter eC2M = new EncounterCharacter( "CharForTestC2" ); // ge eC2M.adjustQuality(QUAL_STRENGTH, 40.0f ); // aq eC2M.adjustQuality(QUAL_STAMINA, 20.9876f ); // aq Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  49. Listing page 5 TestExecution.printReportToFile( outM, "Class test ge-aq-aq-gq-so: part 1", eC2M.getQualityValue( QUAL_STAMINA ), 20.9876f ); // gq TestExecution.printReportToFile( outM, "Class test ge-aq-aq-gq-so: part 2", eC2M.sumOfQualities(), 100.0f ); // so /* INVARIANT-ORIENTED TESTS * Check for the invariant “qualValueI[i] >=0” * -- after executing the sequences of methods executed above */ boolean truthM = true; for( int i = 0; i < qualityTypeS.length; ++i ) { /* Set truthM false if any entry in eC1M.qualValueI not >= 0 */ truthM = truthM && ( eC1M.qualValueI[i] >= 0.0f ); } TestExecution.printReportToFile( outM, "Class test for the invariant 'qualValueI[i] >=0'", truthM, true ); /* Conclude */ outM.close(); System.out.println( "\nClass tests of EncounterChar class concluded." ); } // end of testEncounterCharacterClass Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  50. Listing page 6 /** Tests all the methods of this class one at a time * @param destinationP Location to write results. * @exception IOException If there’s a problem opening or accessing destinationP */ public static void testEncounterCharacterMethods( String destinationP ) throws IOException { /* Prepare for the test */ FileWriter outM = new FileWriter( new File( destinationP ) ); System.out.println( "EncounterCharacter method test results on " + destinationP + "\n" ); /* Tests for getEncounterCharacter() */ EncounterCharacter eCNorM = new EncounterCharacter( "qwerty" ); // normal TestExecution.reportToFile( outM, "GetCharacter Test 1: nominal value", eCNorM.getName(), "qwerty" ); EncounterCharacter eCNullM = new EncounterCharacter( null ); // null TestExecution.reportToFile( outM, "GetCharacter Test 2: null parameter", eCNullM.getName(), GameCharacter. DEFAULT_NAME); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

More Related