Level Game

advertisement
LEVEL GAME
Unit Testing
UML COMPLEXIT Y
 Purpose of UML is to communicate
 Agile manifesto: value working software over comprehensive
documentation
 Does NOT mean no documentation ever!
 UML is used especially to show relationships between classes
 Do we need all the GameEngine details?
 In fact, do all the GameEngine methods need to be public?
 Would any other class call these methods?
UML
WITH PRIVATE METHODS
TEST INDIVIDUAL PIECES
 Create pieces array
 Call move or interact
 Use getters or return type to verify correct behavior
 Test ends (don’t go <0 or >GameEngine.BOARD_SIZE -1)
 If interact with adjoining piece, put that piece & yours on
board
 If interact within range, be sure to test locations within range
PLUS one beyond
TEST RANDOM MOVEMENT
 Can’t test random behavior deterministically
 Need to run method multiple times
 Do all possible results actually occur?
 Do the possible results account for ALL results? (i.e., no invalid
moves)
 What if LOTS of valid results? (e.g., any location)
 Test ends
 Identify “categories” of possibilities
 If limited number of possibilities, test each one
 E.g., move one to right or left
TEST INTERACTION
 What if the player is within “range” of more than one piece?
 We’re not testing this, but the approach would be:




Create a GameEngine
Create a pieces array
Add a setter to GameEngine for the pieces array
Call interaction
BLACK BOX VS WHITE BOX
Criteria
Black Box Testing
White Box Testing
Definition
Black Box Testing is a software testing
method in which the internal structure/
design/ implementation of the item being
tested is NOT known to the tester
White Box Testing is a software
testing method in which the
internal structure/ design/
implementation of the item being
tested is known to the tester.
Mainly applicable to lower levels of
Mainly applicable to higher levels of testing:
Levels Applicable
testing:
Acceptance Testing
To
Unit Testing
System Testing
Integration Testing
Responsibility
Programming
Knowledge
Implementation
Knowledge
Basis for Test
Cases
Generally, independent Software Testers
Generally, Software Developers
Not Required
Required
Not Required
Required
Requirement Specifications
Detail Design
From: http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-box-testing/
TEST COVERAGE (WHITE BOX)
 How much of your code are you actually testing?
 With a par tner, how would you test all paths?
 http://testersthoughtsuncombed.blogspot.com/2013/02/statement -coverage-vsbranch-coverage.html
public static int doSomething(int x, int y, int z) {
int val = 100;
if (x > y)
val += 10;
if (x < z)
val += 20;
if (z > 20) {
val += 100;
System.out.println("here");
}
return va l;
}
 How to address? (on your own)
 http://www.onjava.com/pub/a/onjava/2007/03/02/statement -branch-and-pathcoverage-testing-in-java.html
BASIS PATH TESTING (WHITE BOX)




Analyze control flow graph
Find linearly independent paths of execution
Guarantees complete branch coverage
Does not cover all possible paths
 h t t p : / / w w w. t uto r i al s po i n t .c o m/ s o f t wa r e_ te s t i n g _ d ic t i o n ar y / ba si s _ pa t h_ te st i n g . h t m
 h t t p : / / us e r s .c s c . c al p o l y. e d u/ ~ j d al b ey / 2 0 6 / L ec t ur e s / b a s i s p a t h E g .h t m l
CLASS PARTICIPATION: With your partner: create flow chart to illustrate
covering all branches but not all possible paths
ALL PAIRS TESTING
 Method to test all the possible discrete combinations of the
parameters involved.
 h t t p : / / w w w. t uto r i al s p o i n t .c o m/ s o f t wa r e_ te s t i n g _ d ic t i o n ar y / al l _ p a i r s _ te s t i n g . h t m
CLASS PARTICIPATION: With your partner, think of some examples that might
illustrate this point.
Download
Random flashcards
Radioactivity

30 Cards

History of Europe

27 Cards

Create flashcards