Transcript Chapter 6 : Testing - Texas Tech University

An Introduction to
Programming and Object
Oriented Design using Java
3rd Edition. Dec 2007
Jaime Niño
Frederick Hosch
Chapter 6 : Testing
Functional Testing
 Goal of functional testing: determine system meets
customer’s specifications.
 black box testing:
 test designer ignores internal structure of
implementation.
 Test driven by expected external behavior of the
system
 System is treated as a “black box”: behavior can be
observed, but internal structure is unknown.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
1
Test design
 Test design generally begins with an analysis of
 Functional specifications of system, and
 Use cases: ways in which the system will be used .
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
2
Test plan and test cases
 A test case is defined by
 Statement of case objectives;
 Data set for the case;
 Expected results.
 A test plan is a set of test cases.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
3
Unit Testing
 Unit testing: incremental test of classes as they are
developed.
 Unit testing and implementation are complementary
activities, done concurrently.
 Unit testing is part of system implemention job.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
4
Unit testing
 Requires development of a test plan.
 Test plan is expressed in the testing code itself.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
5
Unit testing
 Implementation driven testing : tests for a module are
developed based upon its implementation.
 Knowledge of implementation is used to select and
refine test cases.
 Example, testing code that contains an if-then-else
statement:
 Write tests for both branches of if-then-else.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
6
Unit testing
 Test driven implementation: tests for a feature are
written before implementing the feature.
 Tests are based on specifications.
 Tests provide a concrete goal for implementation: write
implementation that satisfies tests.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
7
JUnit testing framework
 A collection of classes that simplify testing.
 Construct and run tests using the tools provided by
JUnit.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
8
Testing Pile using JUnit
public class Pile
Models a pile of sticks for playing simple nim.
public Pile (int sticks)
Create new Pile with specified number of sticks.
require:
sticks >= 0
public int sticks ()
The number of sticks remaining in this Pile.
ensure:
this.sticks() >= 0
public void remove (int number)
Reduce number of sticks by specified amount.
require:
number >= 0 and number <= this.sticks()
ensure:
this.sticks() == old.sticks() - number
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
9
PileTest class
 Place the Pile test class in same package where Pile
class is, and import JUnit framework.
package nimGame;
import org.junit.*;
import static org.junit.Assert.*;
/**
* Test the class Pile.
*/
public class PileTest {
…
}
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
10
PileTest class
 test fixture :collection of objects on which a test is to be
performed.
 Pile test fixture:
 Pile created with no sticks
 Pile created with several sticks.
private Pile minPile;
private Pile typicalPile;
Dec 2007
// a Pile of 0 sticks
// a Pile of 5 sticks
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
11
PileTest class: JUnit annotations
 @Test: tells JUnit that method to which it is attached
should be run as a test case.
 @Before tells JUnit that method should be run before
each test case.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
12
PileTest class
@Before
public void setUp () {
minPile = new Pile(0);
typicalPile = new Pile(5);
}
@Test
public void testInitialState () {
assertEquals("min",0,minPile.sticks());
assertEquals("typical",5,typicalPile.sticks());
}
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
13
PileTest class
@Test
public void testRemove () {
// Remove 0
minPile.remove(0);
typicalPile.remove(0);
assertEquals("min remove 0", 0,minPile.sticks());
assertEquals("typical remove 0", 5, typicalPile.sticks());
//Remove 2
typicalPile.remove(2);
assertEquals("typical remove 2", 3, typicalPile.sticks());
// Remove all remaining sticks
typicalPile.remove(typicalPile.sticks())
assertEquals("typical remove all", 0, typicalPile.sticks());
}
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
14
Digit by digit lock
 This lock has a 3 digit combination.
 To open the lock, client provides the digits one at a
time.
 If client enters three digits of combination in order, lock
opens.
 It doesn’t matter how many digits client provides, as
long as combination is given.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
15
Testing a digit-by-digit combination lock
public boolean isOpen ()
This lock is unlocked.
public void close ()
Lock this lock.
public void enter (int digit)
Enter a digit of the combination;
unlocks if the digits of
the combination are entered in order.
require:
digit >= 0 && digit <= 9
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
16
Digit by digit lock: combination 23
Dec 2007
Digit Entered
4
3
1
2
3
Lock Status
locked
locked
locked
locked
unlocked
Digit Entered
1
2
3
4
7
Lock Status
locked
locked
unlocked
unlocked
unlocked
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
17
Digit by digit lock: combination 23
 if client gives command close when combination has
been partly entered,
Client Command
Lock Status
enter (2)
close()
enter (3)
locked
locked
locked
enter(2)
locked
close
enter 3
locked
locked
 command close resets lock, entire combination must be
entered.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
18
Developing test plan: Test cases
 cases in which lock is open, and cases in is closed;
 cases in which first digit of combination has been
entered, and cases in which it has not;
 cases with various combinations.
 equivalency groups:
 combinations specified with a single digit integer
 combinations in which the two digits are different,
such as 12;
 combinations in which the two digits are the same,
such as 77.
 It is also a good idea to test the boundaries: that is,
the largest (99) and smallest (00) combinations.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
19
Test plan
 Test initial state:
 Test the lock is initially open.
 Test opening the lock:
 The lock is already opened.
 Test that entering digits will not close an opened lock.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
20
Test plan
 The lock is closed.
 The lock is reset.
Test entering correct combination opens lock.
Test entering incorrect combination doesn’t open
lock.
 The lock is almost open. (first digit has been entered)
Test an almost open lock remains almost open if
digit entered is not the correct second digit, but
correct first digit.
Test an almost open lock is reset if digit entered is
neither first nor second digit of combination.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
21
Test plan
 Test closing the lock:
 Test an open lock is closed and reset after executing
close.
 Test a reset lock remains reset after executing close.
 Test an almost open lock is reset after executing close
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
22
Implementing test plan
public class CombinationLockTest {
// Locks with the specified combinations
private CombinationLock lock00; // comb.
private CombinationLock lock01; // comb.
private CombinationLock lock12; // comb.
private CombinationLock lock99; // comb.
00
01
12
99
@Before
public void setUp () {
lock00 = new CombinationLock(0);
lock01 = new CombinationLock(1);
lock12 = new CombinationLock(12);
lock99 = new CombinationLock(99);
}
…
}
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
23
Implementing test plan
@Test
public void testOpenLock () {
lock12.enter(3); lock12.enter(4);
assertTrue(lock12.isOpen());
}
@Test
public void testFirstDigitTwice () {
closeLocks();
firstDigitTwice(lock01,0,1);
firstDigitTwice(lock12,1,2);
}
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
24
Implementing test plan
@Test
public void testIncorrectSecondDigit () {
closeLocks();
incorrectSecondDigit(lock01,0,2,1);
incorrectSecondDigit(lock12,1,0,2);
}
@Test
public void testFirstDigitTwice () {
closeLocks();
firstDigitTwice(lock01,0,1);
firstDigitTwice(lock12,1,2);
}
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
25
Implementing test plan
Dec 2007
@Test
public void testCloseOpenedLock () {
lock12.enter(1);
lock12.close();
assertFalse(lock12.isOpen());
// Verify the lock is reset:
lock12.enter(2);
assertFalse(lock12.isOpen());
}
@Test
public void testCloseResetLock () {
lock12.close();
lock12.close();
assertFalse(lock12.isOpen());
}
@Test
public void testCloseAlmostOpenLock () {
closeLocks();
closeAlmostOpenLock(lock00,0,0);
closeAlmostOpenLock(lock01,0,1);
closeAlmostOpenLock(lock12,1,2);
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
}
26
Do we need to test everything?
 Time spent testing is more than made up for in time not
spent debugging.
 Test development is part of design. Time spent
developing test cases pays dividends in design and
implementation.
 The unit tests you develop are part of the product. They
will be used by maintenance programmers to help insure
that future modifications do not break existing parts of
the system. The test you write might be ultimately used
to test code substantially more complex than the code
you write.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
27
Do we need to test everything?
 Finally, as suggested by J. B. Rainsberger, testing
generally goes like this.
Become timid and test everything.
Become more aggressive.
Write fewer tests.
Write tests for more interesting cases.
Get burned by stupid defect.
Feel stupid.
Become timid and test everything.
Dec 2007
NH-Chapter 6: An Introduction To Programming And
Object Oriented Design Using Java
28