Unit Testing

CSIS 3701: Advanced Object Oriented Programming

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

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

functioninput desired output

methodinput desired output

current state desired next state

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?

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()); }

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

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

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

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?

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 listIs new name not in list?

Are existing names unchanged?

Is current unchanged?

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

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

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

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());

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!

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

Drivers

• Simple program to test other code• Example: function driver for C++ sqrt function

int main() { double test; while(1) { cout << “Enter test case: “; cin >> test; cout << sqrt(test) << ‘\n’; } }

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

Constructorsand methods

main methodto test these

NameList.java

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());

}

}

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

Planning Test Cases

VerifyConstructorNameList()

Verifyinspector

toString()

Must be able to view state before testing methods

Example: NameList class

Verifyadd(String)in cases with

no error

Must be able to add names before testing ability to view names

VerifygetNamesAsArray(),getNamesByIndex()

inspectors

Verify isIn(String),isFull()inspectors

Verifyadd(String)in cases withfull list, name already in list