1. An Introduction to Programming and Object Oriented Design using Java 2 nd Edition. May 2004 Jaime Niño Frederick Hosch Chapter 6 : Testing

2. 1May 2004NH-Chapter X Objectives ñAfter studying this chapter you should understand the following: ñfunctional testing and unit testing, their similarities and differences; ñimplementation driven testing vs. test driven implementation; ñthe role of a test plan. ñAlso, you should be able to: ñimplement a test plan with a test class.

3. 2May 2004NH-Chapter X 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.

4. 3May 2004NH-Chapter X 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.

5. 4May 2004NH-Chapter X 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.

6. 5May 2004NH-Chapter X 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.

7. 6May 2004NH-Chapter X Unit testing ñRequires development of a test plan. ñTest plan is expressed in the testing code itself.

8. 7May 2004NH-Chapter X 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.

9. 8May 2004NH-Chapter X 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.

10. 9May 2004NH-Chapter X Developing test plan ñAnalyze feature to identify test cases. ñConsider set of possible states object can assume.  CombinationLock command open ñopen a closed lock with correct combination; ñopen an already opened lock with correct combination; ñattempt to open a closed lock with incorrect combination; ñattempt to open an already opened lock with incorrect combination.

11. 10May 2004NH-Chapter X Developing test plan ñTests must be representative. ñPartition data into equivalency groups. ñValues are considered to be in the same group if they are not likely to test differently. ñ Test cases are chosen from each equivalency group. ñConsider boundary cases.

12. 11May 2004NH-Chapter X Developing test plan ñIn CombinationLock : ñOne equivalence group: all combinations are treated similarly ñTest “representative” combination (123), and ñtwo boundary cases: ñSmallest allowed combination (0), ñLargest allowed (999).

13. 12May 2004NH-Chapter X Developing test plan ñConsider testing sequences of commands. ñTesting Counter  Test reset and incrementCount methods.  Test incrementCount followed by incrementCount ;  Test incrementCount followed by reset ;  reset followed by incrementCount ;  reset followed by reset.

14. 13May 2004NH-Chapter X Testing digit-by-digit combination lock ñSimplify example with a two digit combination lock. ñTest cases: ñcases in which lock is open; ñcases in which the lock is closed; ñcases in which the first digit of the combination has been entered; ñcases in which no digit has been entered; ñcases with various combinations.

15. 14May 2004NH-Chapter X Testing digit-by-digit combination lock ñEquivalency groups: ñcombinations specified with a single digit integer (the first digit is implicitly 0); ñcombinations in which the two digits are different, ñcombinations in which the two digits are the same ñlargest (99) combination ñsmallest (00) combination. ñTest locks combinations 0 (i.e., 00), 1 (i.e., 01), 12, and 99.

16. 15May 2004NH-Chapter X Testing digit-by-digit combination lock ñNumber of tests: ñFour combination values, ñTwo values for “is open,” ñTwo value for “first digit has been entered,” ñ16 interesting states to test.

17. 16May 2004NH-Chapter X Testing digit-by-digit combination lock ñTest initial state: Test the lock is initially open. ñTest opening the lock: ñThe lock is already opened: entering an incorrect combination will not cause an open lock to close.

18. 17May 2004NH-Chapter X Testing digit-by-digit combination lock ñTest initial state: Test the lock is initially open. ñTest opening the lock: ñLock is closed. ñLock is reset. ñentering correct combination opens the lock. ñentering an incorrect combination doesn’t open the lock. ñLock is almost open. (one digit has been entered) ñcorrect first digit is followed by an incorrect second digit. ñfirst digit of combination is entered twice. ñlock is reset if digit entered is neither first nor second digit.

19. 18May 2004NH-Chapter X Testing digit-by-digit combination lock ñTest closing the lock:  Test that an open lock is closed and reset after executing close.  Test that a reset lock remains reset after executing close.  Test that an almost open lock is reset after executing close.

20. 19May 2004NH-Chapter X Implementing tests private CombinationLock lock00; // lock with comb. 00 private CombinationLock lock01; // lock with comb. 01 private CombinationLock lock12; // lock with comb. 12 private CombinationLock lock99; // lock with comb. 99

21. 20May 2004NH-Chapter X Implementing tests ñIt will also be handy to have an auxiliary method to close the locks: private void setUp () { lock00 = new CombinationLock(0); lock01 = new CombinationLock(1); lock12 = new CombinationLock(12); lock99 = new CombinationLock(99); } private void closeLocks () { lock00.close(); lock01.close(); lock12.close(); lock99.close(); }

22. 21May 2004NH-Chapter X Implementing tests ñInitial state test will only test that the lock is open. ñdon’t need to check each lock in the test fixture. private void testInitialState () { setUp(); verify(lock12.isOpen(),"Initially open: lock 12"); }

23. 22May 2004NH-Chapter X Implementing tests ñWrite five tests to verify that the lock opens properly. private void testOpenLock () Test that entering an incorrect combination does not close an open lock. private void testCorrectCombination () Test that entering the correct combination opens a lock. private void testIncorrectCombination () Test that entering an incorrect combination doesn’t open a lock. private void testFirstDigitTwice () Test that entering the first combination digit twice leaves the lock almost open (unless two combination digits are the same). private void testCorrectFirstDigit () Test entering first combination digit followed by incorrect digit different from first leaves lock reset.

24. 23May 2004NH-Chapter X Implementing tests ñTo test that a lock closes properly (3 cases.) private void testCloseOpenedLock () Test that an open lock is closed and reset after executing close. private void testCloseResetLock () { Test that a reset lock remains reset after executing close. private void testCloseAlmostOpenLock () Test that an almost open lock is reset after executing close.

25. 24May 2004NH-Chapter X Summary ñConsidered the problem of testing. ñTesting can demonstrate that a system contains errors, but can never completely guarantee a system’s correctness.

26. 25May 2004NH-Chapter X Summary ñFunctional testing: tests system to verify that it meets the customer’s specifications. ñFunctional tests are designed from the functional specifications of the system. ñThey are generally “black box tests,” : test external system behavior while treating implementation structure as unknown. ñFunctional testing, is often the responsibility of a separate team different from development team.

27. 26May 2004NH-Chapter X Summary ñUnit tests verify that a systems components work properly. ñUnit tests are the responsibility of programmers developing components and are part of the job of implementing the system.

28. 27May 2004NH-Chapter X Summary ñAll testing requires the development of a test plan. ñA test plan describes tests to be conducted: ñPurpose of test, ñdata to be used in the test, ñexpected results. ñFor unit testing, the test plan is formalized in the test code itself. ñFor functional testing, test plan is an independent document that directs the testing.

29. 28May 2004NH-Chapter X Summary ñDeveloping a test plan involves identifying a number of cases to be tested. ñIn a functional test, these “use cases” describe ways in which the system will be used. ñIn a unit test, cases are often determined by possible states of object under test. ñBehavior of object is tested in any number of representative or critical states.