LEVEL GAME
Unit Testing
UNIT TESTING IS NOT JUST JAVA
https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
 Syntax varies based on framework
 TDD goals are the same regardless of language
 Approach to unit testing (e.g., what to test) is same/similar for
various languages
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/
WHAT TO TEST
TEST INTERACTION
 Create pieces array
 Call interact
 Use getters or return type to verify correct behavior
 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 MOTION
 Create pieces array
 Call move
 Use getters or return type to verify correct behavior
 Test ends (don’t go <0 or >GameEngine.BOARD_SIZE -1)
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 MULTIPLE 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
 This would not be in the scope of unit testing pieces. This
might be a unit test for the GameEngine. BUT, tests need to
run quickly. Can’t test every scenario.
TEST COVERAGE
EMMA
EMMA CODE COVERAGE
 http://www.eclemma.org/
 Not required for 306, but useful tool (some companies strive
for close to 100% test coverage)
 Run the tests, see what parts of your code were/were not
tested
SNIPER INTERACT COVERED
Entire interact method was tested
DOORMAT NOT COVERED - OK
• move method of RandomMotionPiece and Minion not covered – shouldn’t be
• other move-related (e.g., setLocation) not covered – shouldn’t be
• interact method of Minion not covered. oops
• always returns NONE. Do we need to test? Yes, if this is the spec. Because if
someone changes that, tests will capture.
• LevelEngine not covered – shouldn’t be
PRIZE PARTIALLY COVERED
yellow: 1 of 4 branches missed
Why? my tests are only for location, don’t test if
prize already won (first row)
same
location
prize Won
true
true
true
false
false
true
false
false
T YPO IN TEST
oops, this should be i=11 (kangalo is at location 10)
AN EXAMPLE
TEST COVERAGE (WHITE BOX)
 How much of your code are you actually testing?
 http://testersthoughtsuncombed.blogspot.com/2013/02/statement coverage-vs-branch-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;
return va l;
Quick: w/o looking at next slide, what tests
would you write for this? Write down values for x,
y and z (plus return value).
Turn this in for class participation credit
}
 How to address? (on your own)
 http://www.onjava.com/pub/a/onjava/2007/03/02/statement -branchand-path-coverage-testing-in-java.html
PATH COVERAGE
Condition 1: x > y
Condition 2: x < z
Condition 3: z > 20
1
2
3 X
Y
Z
1
2
3
Result
T
T
T
20
10
30
20 > 10
20 < 30
30 > 20
230
T
T
F 15
10
18
15 > 10
15 < 18
18 > 20
130
T
F
T
30
20
25
30 > 20
30 < 25
25 > 20
210
T
F
F 30
20
15
30 > 20
20 < 15
15 > 20
110
F
T
T
15
50
25
15 > 50
15 < 25
25 > 20
220
F
T
F 10
50
15
10 > 50
10 < 25
15 > 20
120
F
F
T
30
50
25
30 > 50
30 < 25
25 > 20
200
F
F
F 30
50
15
30 > 50
30 < 25
15 > 20
100
UNIT TEST
@Test
public void pathTest() {
assertEquals(230,
assertEquals(130,
assertEquals(210,
assertEquals(110,
assertEquals(220,
assertEquals(120,
assertEquals(200,
assertEquals(100,
}
TestCoverage.doSomething(20,
TestCoverage.doSomething(15,
TestCoverage.doSomething(30,
TestCoverage.doSomething(30,
TestCoverage.doSomething(15,
TestCoverage.doSomething(10,
TestCoverage.doSomething(30,
TestCoverage.doSomething(30,
10,
10,
20,
20,
50,
50,
50,
50,
30));
18));
25));
15));
25));
15));
25));
15));
SIDEBAR: CYCLOMATIC COMPLEXIT Y
 Based on linearly independent paths
1
2
3 X
Y
Z
1
2
3
Result
T
T
T 20
10
30
20 > 10
20 < 30 30 > 20
230
T
T
F 15
10
18
15 > 10
15 < 18 18 > 20
130
T
F
T 30
20
25
30 > 20
30 < 25 25 > 20
210
F
T
T 15
50
25
15 > 50
15 < 25 25 > 20
220
Condition 1: x > y
Condition 2: x < z
Condition 3: z > 20
http://www.onjava.com/pub/a/onjava/2007/03/02/statement-branchand-path-coverage-testing-in-java.html
SIDEBAR CC CONTINUED
The cyclomatic complexity of a section of source code is the
number of linearly independent paths within it.
 For instance, if the source code contained no control flow
statements (conditionals or decision points), the complexity
would be 1 , since there would be only a single path through
the code.
 If the code had one single-condition IF statement, there would
be two paths through the code: one where the IF statement
evaluates to TRUE and another one where it evaluates to
FALSE, so the complexity would be 2.
 Two nested single-condition IFs, or one IF with two conditions,
would produce a complexity of 4.
https://en.wikipedia.org/wiki/Cyclomatic_complexity
SIDEBAR CC CONTINUED
 Cyclomatic complexity is determined by drawing a control flow
graph. It’s dif ferent from path coverage because you don’t
test all combinations. In this example, there are 3
independent if statements. So cyclomatic complexity is 6. But
there are 8 possible paths. So path coverage requires 8.
SIDEBAR 2: 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