Unit Testing

 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?

 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

 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

 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

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.
Levels Applicable
To
Mainly applicable to higher levels of testing:
Acceptance Testing
System Testing
Mainly applicable to lower levels of testing:
Unit Testing
Integration Testing
Responsibility Generally, independent Software Testers Generally, Software Developers
Programming
Knowledge
Implementation
Knowledge
Not Required
Not Required
Required
Required
Basis for Test
Cases
Requirement Specifications Detail Design
From: http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-box-testing /

 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

 Analyze control flow graph
 Find linearly independent paths of execution
 Guarantees complete branch coverage
 Does not cover all possible paths
 ht t p:// www.tutorialspoint.com/sof twar e_testing_dictionar y/basis_path_testing.htm
 ht t p://user s.csc.calpoly.edu/~jdalbey/2 06/Lectures/basispathEg.html
CLASS PARTICIPATION: With your partner: create flow chart to illustrate covering all branches but not all possible paths

 Method to test all the possible discrete combinations of the parameters involved.
 ht t p://www.tutorialspoint.com/sof twar e_testing_dictionar y/all_pair s_testing.htm
CLASS PARTICIPATION: With your partner, think of some examples that might illustrate this point.