8. UNIT TESTING
Software Engineering Roadmap: Chapter 8 Focus Plan  project Integrate  & test system Analyze  requirements Design Maintain...
Learning Goals of This Chapter  <ul><li>Understand meaning of unit testing  </li></ul><ul><li>Distinguish black box vs. wh...
1. Introduction to unit testing
Golden Rules of Testing <ul><li>Goal of testing : maximize the number and severity of defects found per dollar spent …  th...
Testing: the Big Picture Methods Combinations of methods in class  Packages  of classes OO: Include use-cases Function  Mo...
Unified Process Elaboration Inception Construction Transition Requirements Analysis Design Implemen- tation Test Jacobson ...
RoadMap for Unit Testing 1. Plan for  unit testing Requirements Unit test plan 2. Design test  cases and acquire  test I/O...
2. Test types
Black-, Gray-,  & White-box Testing Black box …  requirements Actual  output compared  with   required  output White box G...
Black-box testing
Equivalence Partitioning <ul><li>Input data and output results often fall into different classes where all members of a cl...
Equivalence Partitioning
Test Input Possibilities interest rate 0% 25% principal $100 $100M inflation estimate 1% 20% Infinitely many legal values:...
Test Input Partitioning and Boundaries interest rate 0% 25% principal $100 $100M inflation estimate Boundaries 1% 20% Equi...
Testing Ranges: Elementary Cases <ul><li>1. within range </li></ul><ul><li>2. at the boundaries  </li></ul><ul><li>of the ...
<ul><li>Requirement: The system must accept a 5-digit integer between 10000 and 99999 and perform various functions on the...
Equivalence Partitions B e t w e e n 1 0 0 0 0 a n d 9 9 9 9 9 L e s s t h a n 1 0 0 0 0 M o r e t h a n 9 9 9 9 9 9 9 9 9...
White Box Testing <ul><li>Every statement of code should be covered by at least one test </li></ul><ul><li>However,  this ...
Covering Every Statement is Not Sufficient  (Myers) u>1 and v==0 x = x/u u==2 or x>0 ++x No Yes No Yes Required  program
Covering Every Statement is Not Sufficient  (Myers) u>1 and v==0 x = x/u u==2 or x>0 ++x No Yes <ul><li>Code attempt to im...
Paths to be Checked Parameter & settings make sense? Parameter name too long? N Y N Set _name to  “ defaultName&quot; Y Tr...
Paths to be Checked Parameter & settings make sense? Parameter name too long? N Y N Decision Coverage Set _name to  “ defa...
Decision Coverage via Path testing <ul><li>The objective of path testing is to ensure that the set of test cases is such t...
<ul><li>Describes the program control flow. Each branch is shown as a separate path and loops are shown by arrows looping ...
<ul><li>The number of tests to test all control  statements equals the cyclomatic complexity </li></ul><ul><li>Cyclomatic ...
Binary search (Java)
Binary search flow graph
<ul><li>1, 2, 3, 8, 9 </li></ul><ul><li>1, 2, 3, 4, 6, 7, 2 </li></ul><ul><li>1, 2, 3, 4, 5, 7, 2 </li></ul><ul><li>1, 2, ...
Grey Box Testing <ul><li>Combination of Black and White box testing </li></ul>Gray box …  requirements & key design elemen...
<ul><li>Pre-conditions satisfied, key element in array </li></ul><ul><li>Pre-conditions satisfied, key element not in  arr...
Binary search equiv. partitions
Binary search - test cases
3. Planning unit tests
Plan for Unit Testing <ul><li>1.  Decide on the philosophy for unit testing </li></ul><ul><ul><li>individual engineer resp...
4. Checklists and examples for Method testing
Perform Method Testing (Humphrey) 1/2 <ul><li>1.  Verify operation at  normal parameter  values   </li></ul><ul><ul><li>(a...
Perform Method Testing (Humphrey) 2/2 <ul><li>9. Check  normal  termination of all  loops  </li></ul><ul><ul><li>(part of ...
Method Test Case Examples <ul><li>See pages 409-414 and Case Study at end of chapter </li></ul><ul><li>Each Example layout...
5. Checklists and examples for class testing
<ul><li>1.  Exercise methods in combination </li></ul><ul><ul><li>2-5, usually </li></ul></ul><ul><ul><li>choose most comm...
Encounter  State-Transition Test Sequence 1 of 2 Waiting Preparing test step 1 Verify that the game is initially in  Prepa...
Encounter  State-Transition Test Sequence 1 of 2 Waiting Preparing test step 1 test step 2 test step 3 Verify that the gam...
Complete  Encounter  State-Transition Test Player dismisses qualities menu Character enters area inhabited by an opponent ...
<ul><li>Defect testing and debugging are distinct  processes </li></ul><ul><li>Inspection and testing is concerned with es...
The debugging process
6. Summary
Unit Testing: Summary  <ul><li>Unit testing is about “pieces” </li></ul><ul><li>Other testing is about “assemblies” </li><...
Case Study EncounterCharacter.java
Listing  page  1 /** To test this class. *  @param argsP destination of method test log, class test log respectively */ pu...
Listing page  2 // 2. EXECUTE TESTS WHICH DO REQUIRE HUMAN INTERVENTION Frame[] imageTests = { // Display test cases.     ...
Listing  page 3 /**  Tests this class by executing its methods in combination.  * @param destinationP Location to write re...
Listing  page  4   *   *   The following sequences occur commonly:   *   ge-aq-so   *   ge-sq-a-gq   *   . . . . .    *   ...
Listing  page  5 TestExecution.printReportToFile( outM, &quot;Class test ge-aq-aq-gq-so: part 1&quot;, eC2M.getQualityValu...
Listing page  6 /**  Tests all the methods of this class one at a time * @param  destinationP  Location to write results. ...
Listing page  7 String tooLongM = &quot;1234567890123456789012345678901234567890&quot;;  EncounterCharacter eCTooLongM =  ...
Listing page  8 /* Tests for indexOf() for every valid quality name. */ for (  int  i =   0; i < qualityTypeS.length; ++i ...
Listing page  9 /* Tests for setQuality() */ // Set up for test  EncounterCharacter hank =  new  EncounterCharacter( &quot...
Listing page  10 // Tests for adjustQuality().  // Set up for test and verify: Values should be 20 each. EncounterCharacte...
Listing page  11 <ul><li>/** Class to test repainting of characters. Creates a window, which will contain </li></ul><ul><l...
Listing page  12 <ul><ul><li>/** Repaint the display areaof the frame. </li></ul></ul><ul><ul><li>* @param drawP Graphics ...
Upcoming SlideShare
Loading in...5
×

Ch.8

257

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
257
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ch.8

  1. 1. 8. UNIT TESTING
  2. 2. Software Engineering Roadmap: Chapter 8 Focus Plan project Integrate & test system Analyze requirements Design Maintain Test units Implement Identify corporate practices Test units (parts) separately - use implementations - apply discipline - gain coverage Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  3. 3. Learning Goals of This Chapter <ul><li>Understand meaning of unit testing </li></ul><ul><li>Distinguish black box vs. white box testing </li></ul><ul><li>Attain proper test coverage </li></ul><ul><li>Learn a testing standard </li></ul><ul><li>Inspect a unit test plan </li></ul>Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  4. 4. 1. Introduction to unit testing
  5. 5. Golden Rules of Testing <ul><li>Goal of testing : maximize the number and severity of defects found per dollar spent … thus: test early </li></ul><ul><li>Limits of testing : Testing can only determine the presence of defects, never their absence </li></ul><ul><ul><li>use proofs of correctness to establish “absence ” </li></ul></ul><ul><li>Who should test : Someone other than the developer. </li></ul><ul><ul><li>Why? </li></ul></ul>Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  6. 6. Testing: the Big Picture Methods Combinations of methods in class Packages of classes OO: Include use-cases Function Module Module combination 2. Integration tests 3. System tests 1. Unit tests
  7. 7. Unified Process Elaboration Inception Construction Transition Requirements Analysis Design Implemen- tation Test Jacobson et al : USDP Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k … .. … .. Unit Tests Integration tests ... System tests
  8. 8. RoadMap for Unit Testing 1. Plan for unit testing Requirements Unit test plan 2. Design test cases and acquire test I/O pairs Generate I/O pairs (often products of prior testing) 3. Execute unit test Test set Test results Code under test Detailed design Identify largest trouble spots IEEE, 1986
  9. 9. 2. Test types
  10. 10. Black-, Gray-, & White-box Testing Black box … requirements Actual output compared with required output White box Gray box … requirements & key design elements Input determined by... Result … design elements Confirmation of expected behavior As for black- and white box testing Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  11. 11. Black-box testing
  12. 12. Equivalence Partitioning <ul><li>Input data and output results often fall into different classes where all members of a class are related </li></ul><ul><li>Each of these classes is an equivalence partition where the program behaves in an equivalent way for each class member </li></ul><ul><li>Test cases should be chosen from each partition </li></ul>
  13. 13. Equivalence Partitioning
  14. 14. Test Input Possibilities interest rate 0% 25% principal $100 $100M inflation estimate 1% 20% Infinitely many legal values: choose a finite sample. Infinitely many illegal values: choose a finite sample. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  15. 15. Test Input Partitioning and Boundaries interest rate 0% 25% principal $100 $100M inflation estimate Boundaries 1% 20% Equivalence partitions An illegal region Range of valid inputs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  16. 16. Testing Ranges: Elementary Cases <ul><li>1. within range </li></ul><ul><li>2. at the boundaries </li></ul><ul><li>of the range </li></ul><ul><li>3. outside the range </li></ul><ul><ul><li>(“illegal”) </li></ul></ul>range Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  17. 17. <ul><li>Requirement: The system must accept a 5-digit integer between 10000 and 99999 and perform various functions on the values based on the following equivalence partitions: </li></ul><ul><li> <10000, 10000 - 99999 and >= 100000 </li></ul><ul><li>Which test cases should be chosen? </li></ul><ul><li>Consider the boundaries of these sets … </li></ul><ul><li>00000, 09999, 10000, 99999, 100000, <max bin> </li></ul>Equivalence Partitioning – Example
  18. 18. Equivalence Partitions B e t w e e n 1 0 0 0 0 a n d 9 9 9 9 9 L e s s t h a n 1 0 0 0 0 M o r e t h a n 9 9 9 9 9 9 9 9 9 1 0 0 0 0 5 0 0 0 0 1 0 0 0 0 0 9 9 9 9 9 I n p u t v a l u e s
  19. 19. White Box Testing <ul><li>Every statement of code should be covered by at least one test </li></ul><ul><li>However, this is not sufficient since the correct opeation of a unit of code depends upon sequences of statements </li></ul>
  20. 20. Covering Every Statement is Not Sufficient (Myers) u>1 and v==0 x = x/u u==2 or x>0 ++x No Yes No Yes Required program
  21. 21. Covering Every Statement is Not Sufficient (Myers) u>1 and v==0 x = x/u u==2 or x>0 ++x No Yes <ul><li>Code attempt to implement flowchart </li></ul><ul><li>if( (u>1) && (v==0) ) (1) </li></ul><ul><li>x = x/u; (2) </li></ul><ul><li>if( (u==2) || (x>3) ) (3) </li></ul><ul><li>++x; (4) </li></ul><ul><li>u=2, v=0 and x=3 </li></ul><ul><li>executes every line (1) - (4) </li></ul><ul><li>gives the correct output x= 2.5 </li></ul><ul><li>However, line (3) is wrong </li></ul><ul><li>SO THIS IS NOT A THOROUGH TEST </li></ul>No Yes Required program
  22. 22. Paths to be Checked Parameter & settings make sense? Parameter name too long? N Y N Set _name to “ defaultName&quot; Y Truncate name Set _name to parameter
  23. 23. Paths to be Checked Parameter & settings make sense? Parameter name too long? N Y N Decision Coverage Set _name to “ defaultName&quot; Y Truncate name Set _name to parameter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  24. 24. Decision Coverage via Path testing <ul><li>The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once </li></ul><ul><li>The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control </li></ul><ul><li>Statements with conditions are therefore nodes in the flow graph </li></ul>
  25. 25. <ul><li>Describes the program control flow. Each branch is shown as a separate path and loops are shown by arrows looping back to the loop condition node </li></ul><ul><li>Used as a basis for computing the cyclomatic complexity </li></ul><ul><li>Cyclomatic complexity = Number of edges - Number of nodes +2 </li></ul>Program flow graphs
  26. 26. <ul><li>The number of tests to test all control statements equals the cyclomatic complexity </li></ul><ul><li>Cyclomatic complexity equals number of conditions in a program </li></ul><ul><li>Useful if used with care. Does not imply adequacy of testing. </li></ul><ul><li>Although all paths are executed, all combinations of paths are not executed </li></ul>Cyclomatic complexity
  27. 27. Binary search (Java)
  28. 28. Binary search flow graph
  29. 29. <ul><li>1, 2, 3, 8, 9 </li></ul><ul><li>1, 2, 3, 4, 6, 7, 2 </li></ul><ul><li>1, 2, 3, 4, 5, 7, 2 </li></ul><ul><li>1, 2, 3, 4, 6, 7, 2, 8, 9 </li></ul><ul><li>Test cases should be derived so that all of these paths are executed </li></ul><ul><li>A dynamic program analyser may be used to check that paths have been executed </li></ul>Independent paths
  30. 30. Grey Box Testing <ul><li>Combination of Black and White box testing </li></ul>Gray box … requirements & key design elements Correct output and expected behaviour
  31. 31. <ul><li>Pre-conditions satisfied, key element in array </li></ul><ul><li>Pre-conditions satisfied, key element not in array </li></ul><ul><li>Pre-conditions unsatisfied, key element in array </li></ul><ul><li>Pre-conditions unsatisfied, key element not in array </li></ul><ul><li>Input array has a single value </li></ul><ul><li>Input array has an even number of values </li></ul><ul><li>Input array has an odd number of values </li></ul>Grey Box Testing Example Binary search - equiv. partitions
  32. 32. Binary search equiv. partitions
  33. 33. Binary search - test cases
  34. 34. 3. Planning unit tests
  35. 35. Plan for Unit Testing <ul><li>1. Decide on the philosophy for unit testing </li></ul><ul><ul><li>individual engineer responsible (common)? </li></ul></ul><ul><ul><li>reviewed by others? </li></ul></ul><ul><ul><li>designed & performed by others? </li></ul></ul><ul><li>2. Decide what / where / how to document </li></ul><ul><ul><li>individual’s personal document set (common)? </li></ul></ul><ul><ul><li>how / when to incorporate into other types of testing? </li></ul></ul><ul><ul><li>incorporate in formal documents? </li></ul></ul><ul><ul><li>use tools / test utilities? </li></ul></ul><ul><li>3. Determine extent of unit testing (i.e., in advance). </li></ul><ul><ul><li>do not just “test until time expires” </li></ul></ul><ul><ul><li>prioritize, so that important tests definitely performed </li></ul></ul><ul><li>4. Decide how and where to get the test input </li></ul><ul><li>5. Estimate the resources required </li></ul><ul><ul><li>use historical data if available </li></ul></ul><ul><li>6. Arrange to track time, defect count, type & source </li></ul>One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  36. 36. 4. Checklists and examples for Method testing
  37. 37. Perform Method Testing (Humphrey) 1/2 <ul><li>1. Verify operation at normal parameter values </li></ul><ul><ul><li>(a black box test based on the unit’s requirements) </li></ul></ul><ul><li>2. Verify operation at limit parameter values </li></ul><ul><ul><li>(black box) </li></ul></ul><ul><li>3. Verify operation outside parameter values </li></ul><ul><ul><li>(black box) </li></ul></ul><ul><li>4. Ensure that all instructions execute </li></ul><ul><ul><li>(statement coverage) </li></ul></ul><ul><li>5. Check all paths , including both sides of all branches </li></ul><ul><ul><li>(decision coverage) </li></ul></ul><ul><li>6. Check the use of all called objects </li></ul><ul><li>7. Verify the handling of all data structures </li></ul><ul><li>8. Verify the handling of all files </li></ul>One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  38. 38. Perform Method Testing (Humphrey) 2/2 <ul><li>9. Check normal termination of all loops </li></ul><ul><ul><li>(part of a correctness proof) </li></ul></ul><ul><li>10. Check abnormal termination of all loops </li></ul><ul><li>11. Check normal termination of all recursions </li></ul><ul><li>12. Check abnormal termination of all recursions </li></ul><ul><li>13. Verify the handling of all error conditions </li></ul><ul><li>14. Check timing and synchronization </li></ul><ul><li>15. Verify all hardware dependencies </li></ul>One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  39. 39. Method Test Case Examples <ul><li>See pages 409-414 and Case Study at end of chapter </li></ul><ul><li>Each Example layouts Input, Execution and Expected Output </li></ul><ul><li>Test code is developed to exercise the methods and output the specifics of the tests (as above) and the actual results to a file for analysis </li></ul>
  40. 40. 5. Checklists and examples for class testing
  41. 41. <ul><li>1. Exercise methods in combination </li></ul><ul><ul><li>2-5, usually </li></ul></ul><ul><ul><li>choose most common sequences first </li></ul></ul><ul><ul><li>include sequences likely to cause defects </li></ul></ul><ul><ul><li>requires hand-computing the resulting attribute values </li></ul></ul><ul><li>2. Focus unit tests on each attribute </li></ul><ul><ul><li>initialize, then execute method sequences that affect it </li></ul></ul><ul><li>3. Verify that each class invariant is unchanged </li></ul><ul><ul><li>verify that the invariant is true with initial values </li></ul></ul><ul><ul><li>execute a sequence (e.g., the same as in 1.) </li></ul></ul><ul><ul><li>verify that the invariant still true </li></ul></ul><ul><li>4. Verify that objects transition among expected states </li></ul><ul><ul><li>plan the state / transition event sequence </li></ul></ul><ul><ul><li>set up the object in the initial state by setting variables </li></ul></ul><ul><ul><li>provide first event & check that transition occurred . etc. </li></ul></ul>Perform Class Unit Tests One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  42. 42. Encounter State-Transition Test Sequence 1 of 2 Waiting Preparing test step 1 Verify that the game is initially in Preparing state (by checking on the class membership of gameStateI ) Player dismisses qualities menu
  43. 43. Encounter State-Transition Test Sequence 1 of 2 Waiting Preparing test step 1 test step 2 test step 3 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. Move the player character to an adjacent area, and verify that the game is still in Waiting state. Player dismisses qualities menu Move to adjacent area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  44. 44. Complete Encounter State-Transition Test Player dismisses qualities menu Character enters area inhabited by an opponent Move to adjacent area Waiting Preparing Engaging 1 2 3 4 5 Reporting Player dismisses encounter report menu Encounter completed 6 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  45. 45. <ul><li>Defect testing and debugging are distinct processes </li></ul><ul><li>Inspection and testing is concerned with establishing the existence of defects in a program </li></ul><ul><li>Debugging is concerned with locating and repairing these errors </li></ul><ul><li>Debugging involves formulating a hypothesis about program behaviour then testing these hypotheses to find the error </li></ul>Testing and debugging
  46. 46. The debugging process
  47. 47. 6. Summary
  48. 48. Unit Testing: Summary <ul><li>Unit testing is about “pieces” </li></ul><ul><li>Other testing is about “assemblies” </li></ul><ul><li>Black box: input / output only </li></ul><ul><li>White box: verifies processing </li></ul><ul><ul><li>Several ways , Ensure completeness </li></ul></ul><ul><li>Grey box: a bit of Black and White </li></ul><ul><li>Test planning - earlier the better </li></ul><ul><ul><li>helps clarify requirements </li></ul></ul>Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  49. 49. Case Study EncounterCharacter.java
  50. 50. 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 = &quot;methodOutput.txt&quot;; String classOutputFileNameM= &quot;classOutput.txt&quot;; 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.
  51. 51. Listing page 2 // 2. EXECUTE TESTS WHICH DO REQUIRE HUMAN INTERVENTION Frame[] imageTests = { // Display test cases. new testCharacterImage( // Missing image. new EncounterCharacter( &quot;GuyWithNoImage&quot;, null ) ), new testCharacterImage( // Image is present. new EncounterCharacter( &quot;Elena&quot;, &quot;elena.gif&quot; ) ) }; 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 ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  52. 52. Listing page 3 /** 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( &quot; EncounterCharacter class test results on &quot; + destinationP + &quot; &quot; ); /* * 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() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  53. 53. 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( &quot;CharForTestC1&quot; ); // method “ge” eC1M.adjustQuality(QUAL_STRENGTH, 40.0f ); // aq TestExecution.printReportToFile( outM, &quot;Class test ge-aq-so&quot;, eC1M.sumOfQualities(), 100.0f ); // so /* Test C2: ge-aq-aq-gq-so */ EncounterCharacter eC2M = new EncounterCharacter( &quot;CharForTestC2&quot; ); // 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.
  54. 54. Listing page 5 TestExecution.printReportToFile( outM, &quot;Class test ge-aq-aq-gq-so: part 1&quot;, eC2M.getQualityValue( QUAL_STAMINA ), 20.9876f ); // gq TestExecution.printReportToFile( outM, &quot;Class test ge-aq-aq-gq-so: part 2&quot;, 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, &quot;Class test for the invariant 'qualValueI[i] >=0'&quot;, truthM, true ); /* Conclude */ outM.close(); System.out.println( &quot; Class tests of EncounterChar class concluded.&quot; ); } // end of testEncounterCharacterClass Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  55. 55. 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( &quot;EncounterCharacter method test results on &quot; + destinationP + &quot; &quot; ); /* Tests for getEncounterCharacter() */ EncounterCharacter eCNorM = new EncounterCharacter( &quot;qwerty&quot; ); // normal TestExecution.reportToFile( outM, &quot;GetCharacter Test 1: nominal value&quot;, eCNorM.getName(), &quot;qwerty&quot; ); EncounterCharacter eCNullM = new EncounterCharacter( null ); // null TestExecution.reportToFile( outM, &quot;GetCharacter Test 2: null parameter&quot;, eCNullM.getName(), GameCharacter. DEFAULT_NAME); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  56. 56. Listing page 7 String tooLongM = &quot;1234567890123456789012345678901234567890&quot;; EncounterCharacter eCTooLongM = new EncounterCharacter(tooLongM); // too long TestExecution.reportToFile( outM, &quot;GetCharacter Test 3: Limit parameter values, &quot; + &quot;max name len = &quot; + eCTooLongM .maxNumCharsInName(), eCTooLongM.getName(), tooLongM.substring(0, eCTooLongM.maxNumCharsInName()) ); EncounterCharacter eCZeroM = new EncounterCharacter( &quot;&quot; ); // zero-len TestExecution.reportToFile( outM, &quot;GetCharacter Test 4: zero-length&quot;, eCZeroM .getName(), GameCharacter. DEFAULT_NAME); EncounterCharacter eCPuncM = new EncounterCharacter( &quot;a+b&quot; ); // bad chars TestExecution.reportToFile( outM, &quot;GetCharacter Test 5: bad char '+' &quot;, eCPuncM .getName(), GameCharacter. DEFAULT_NAME); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  57. 57. Listing page 8 /* Tests for indexOf() for every valid quality name. */ for ( int i = 0; i < qualityTypeS.length; ++i ) try { TestExecution.reportToFile( outM, &quot;indexOf() Test 1.&quot; + i + &quot;: valid name: &quot; + qualityTypeS[i], indexOf(qualityTypeS[i]), i ); } catch ( Exception eP ) { TestExecution.reportToFile( outM, &quot;indexOf() Test 1: valid name: compare &quot;, &quot;indexOf('&quot; + qualityTypeS[i] + &quot;')&quot;, &quot;with expected &quot; + i ); } /* Tests for indexOf() for an invalid quality name. */ try { TestExecution.reportToFile( outM, &quot;indexOf() Test 2: invalid name: zorch&quot;, indexOf(&quot;zorch&quot;), -1 ); } catch ( Exception eP ) { TestExecution.reportToFile( outM, &quot;indexOf() Test 2: valid name: compare &quot;, &quot;indexOf(&quot;zorch&quot;)&quot;, &quot;with expected -1&quot; ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  58. 58. Listing page 9 /* Tests for setQuality() */ // Set up for test EncounterCharacter hank = new EncounterCharacter( &quot;Hank&quot; ); // Nominal value hank.setQuality(QUAL_STRENGTH , 10.3f ); TestExecution.reportToFile( outM, &quot;setQuality() Test 1: nominal value&quot;, hank.getQualityValue( QUAL_STRENGTH ), 10.3f ); // Out of range value hank.setQuality( QUAL_PATIENCE, -6.2f ); TestExecution.reportToFile( outM, &quot;setQuality() Test 2: nominal value&quot;, hank.getQualityValue(QUAL_PATIENCE ), 0.0f ); // Value below close-to-zero threshold. hank.setQuality( QUAL_STAMINA, getTolerance() * 0.9f ); TestExecution.reportToFile( outM, &quot;setQuality() Test 3: value close to zero&quot;, hank.getQualityValue(QUAL_STAMINA), 0.0f ); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  59. 59. Listing page 10 // Tests for adjustQuality(). // Set up for test and verify: Values should be 20 each. EncounterCharacter harvey = new EncounterCharacter( &quot;Harvey&quot; ); TestExecution.reportToFile( outM, &quot;adjustQuality() test 0: verify that values add to 100&quot;, harvey.sumOfQualities(), 100.0f ); // Nominal adjustment harvey.adjustQuality(QUAL_STRENGTH , 30.0f ); // strength 30 rest 70/4 each TestExecution.reportToFile( outM, &quot;adjustQuality() test 1: values sum to 100 after adjusting&quot;, harvey.sumOfQualities(), 100.0f ); TestExecution.reportToFile ( outM, &quot;adjustQuality() test 2: values adjusted as commanded&quot;, harvey.getQualityValue(QUAL_STRENGTH ), 30.0f ); // Adjustment resulting in a zero value harvey.adjustQuality( QUAL_STAMINA, 99.0f ); TestExecution.reportToFile( outM, &quot;adjustQuality() test 3: verify low value reverts to zero&quot;, harvey.getQualityValue( QUAL_STRENGTH ), 0.0f ); // Conclude outM.close(); System.out.println( &quot; Method tests of EncounterCharacter class concluded.&quot; ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  60. 60. Listing page 11 <ul><li>/** Class to test repainting of characters. Creates a window, which will contain </li></ul><ul><li>* several copies of the character image. </li></ul><ul><li>*/ </li></ul><ul><li>private static class testCharacterImage extends Frame </li></ul><ul><li>{ </li></ul><ul><ul><li>/** Instance attribute that remembers which character image to display. */ </li></ul></ul><ul><ul><li>private EncounterCharacter characterI; </li></ul></ul><ul><ul><li>/** Basic constructor -- create a window for testing some character's image. </li></ul></ul><ul><ul><li>* @param characterP Character whose image is to be tested. </li></ul></ul><ul><ul><li>*/ </li></ul></ul><ul><ul><li>testCharacterImage(EncounterCharacter characterP) </li></ul></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>super (characterP.getName()); // Do all normal Frame initialization. </li></ul></ul><ul><ul><li>characterI = characterP; // Remember which character we're testing. </li></ul></ul><ul><ul><li>} </li></ul></ul>Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  61. 61. Listing page 12 <ul><ul><li>/** Repaint the display areaof the frame. </li></ul></ul><ul><ul><li>* @param drawP Graphics context for drawing the character. </li></ul></ul><ul><ul><li>*/ </li></ul></ul><ul><ul><li>public void paint(Graphics drawP) </li></ul></ul><ul><ul><li>{ Dimension frameSizeM = getSize(); // Size of the window area. </li></ul></ul><ul><ul><li>int widthUnitM = frameSizeM.width / 5; // Convenient divisions of window. </li></ul></ul><ul><ul><li>int heightUnitM = frameSizeM.height / 5; </li></ul></ul><ul><ul><li>characterI.showCharacter( this , drawP, // Drawn small, facing right. </li></ul></ul><ul><ul><li> new Point(widthUnitM, heightUnitM), heightUnitM, false ); </li></ul></ul><ul><ul><li>characterI.showCharacter( this , drawP, // Drawn large, facing left. </li></ul></ul><ul><ul><li> new Point(widthUnitM*4, heightUnitM*3), heightUnitM*2, true ); </li></ul></ul><ul><ul><li>characterI.showCharacter( this , drawP, // Drawn large, facing right. </li></ul></ul><ul><ul><li> new Point(widthUnitM*2, heightUnitM*2), heightUnitM*2, false ); </li></ul></ul><ul><ul><li>characterI.showCharacter( this , drawP, // Drawn small, facing left. </li></ul></ul><ul><ul><li>new Point(widthUnitM*3, heightUnitM*4), heightUnitM, true ); </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><li>} // End of testCharacterImage inner class </li></ul>Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×