1. Unit Testing CSIS 3701: Advanced Object Oriented Programming

2. Verification and Validation Does support class meet all requirements? Validation –Are there methods and constructors to meet all needs of client programmers? –Done by thorough class design, integration testing Verification –Do individual methods/constructors work correctly? –Done with unit testing

3. Methods vs. Functions Function correctness: –Produces desired output for all legal inputs Method correctness: –Produces desired output and desired next state for all legal inputs and legal current states function inputdesired output method input desired output current statedesired next state

4. Viewing State Method correctness based on resulting object state as well as return value Must be able to view state in order to verify –c.setHour(15); Is hour now 15? –c.setHour(37); Is hour not 37?

5. Viewing State Assumption: Have working toString() method –Returns string showing all member variables –Can print to standard output for debugging: System.out.println(object.toString()); –Can call inside methods (like scaffolding): public boolean add(String name) { … System.out.println(toString()); }

6. Test Case Design Test cases based on requirements –Created during design/analysis –Can be refined to cover all possible outcomes Legal time Illegal time Change time Illegal hour Illegal minute hour < 0 hour > 23 minute < 0 minute > 59

7. Test Case Design Often involves boundary testing –Similar cases with different outcomes –Data structures nearly empty/full Clock class: setHour(int h)h : …-1 | 0 … 23 | 24 NameList class: add(String name) current : …0 | 1 … maximum - 1 | maximum

8. Constructors Must put object in correct initial state –Based on any parameters –Must test each overloaded constructor Examples: – Clock()  test hour == 0, minute == 0 – Clock(13,37)  test hour == 13, minute == 37 – NameList(5)  test maximum == 5 current == 0 no names in list

9. Modifiers Must put object in correct state –At least one test for each way state can be changed nextMinute() in Clock class –Simple minute increment  time = 11:23 –Increment hour  time = 11:59 –Reset hour to 0  time = 23:59 add() in NameList class –Add new name to empty list –Add new name to non-empty list –Add new name to list almost full Is new name in list? Are existing names unchanged? Was current incremented?

10. Modifiers Must do proper validation –At least one test for each way state can be invalid –Boundary testing –Make sure state unchanged add() in NameList class –Add existing name to list Existing name at beginning, middle, end –Add new name to full list Is new name not in list? Are existing names unchanged? Is current unchanged?

11. Inspectors Must return correct information for current state –Correct format –No change to object state –Validation of input (if relevant) getNamesAsArray() –Test on list  returns correct array? –Test on empty list  no errors? getNamesByIndex(int) –Test on values 0 to current - 1 –Boundary tests -1, current should return null No change to names, current, or maximum

12. Inspectors Validation inspectors –At least one test for each way state can be invalid –Boundary testing isFull() –Test on empty list,list with one space left –Test on full list isIn(String) –Test on all names in list –Test on name not in list

13. Planning Test Cases Often need to “set up” tests with method calls –Tests often based on specific state –Use modifiers to put object in necessary state isIn(“Fred”) –Must use add(“Fred”) first to place in list isFull() –Must use add() first to fill up list

14. Planning Test Cases Can “script” test cases: NameList n = new NameList(3); n.add(“a”); n.add(“b”); n.add(“c”); // test for isFull() System.out.println(toString());

15. Testing Support Classes Support class not executable program Need another executable program to run tests –Construct support objects –Call methods –Display/check object state for correctness Key: other “tester” program must be simple –Any errors must be in support class, not tester!

16. NameList Example Main.java Stores names Returns current names Validates list not full, name not already in list NameList.java names Are errors here? Or are they in the testing tool itself? Current application may not use all methods in class

17. Drivers Simple program to test other code Example: function driver for C++ sqrt function int main() { double test; while(1) { cout > test; cout << sqrt(test) << ‘\n’; } }

18. Class Drivers in Java Must be in a main method –Separate testing class –As main in support class itself Idea: keep testing tools as part of class –Do not delete when finished testing Will need again if class modified in future Constructors and methods main method to test these NameList.java

19. Class Drivers in Java Example: Simple driver for add method in NameList public static void main(String[] args) { Scanner s = new Scanner(System.in); NameList test = new NameList(3); while(true) { System.out.print("Enter name: "); String name = s.nextLine(); test.add(name); System.out.println(test.toString()); } }

20. Planning Test Cases Order of tests important –If method depends on other methods/constructor, must verify them first Examples: –Must verify constructor before testing methods –Must verify ability to view state before testing methods –Must verify ability to change state before testing inspectors based on state –Must verify validation inspectors before testing methods that use them for validation

21. Planning Test Cases Verify Constructor NameList() Verify inspector toString() Must be able to view state before testing methods Example: NameList class Verify add(String) in cases with no error Must be able to add names before testing ability to view names Verify getNamesAsArray(), getNamesByIndex() inspectors Verify isIn(String), isFull() inspectors Verify add(String) in cases with full list, name already in list