Week 14

Introduction to Computer Science and Object-Oriented Programming

COMP 111

George Basham

Week 13 Topics

14.1.1 Unit Tests

14.1.2 Providing Test Input

14.1.3 Test Case Evaluation

14.1.4 Regression Testing and Test Coverage

14.1.5 Logging

14.1.6 Using a Debugger

14.1.1 Unit Tests

• Unit tests are used to test classes in isolation of one another

• The Unit Testing framework we have been using in this course is JUnit

• A Unit Testing framework typically allows the programmer to compare a predetermined expected result against the result produced by the program

14.1.1 Unit Tests Cont.

• It is challenging to test a class in isolation if it depends on another class

• Testing classes in isolation when they have dependencies requires an advanced testing technique called mock objects

• Mock objects are objects that are designed specifically for the purpose of testing, but don’t actually implement the functionality of the class being mocked

14.1.1 Unit Tests Cont.

• A Mock class is stuffed with dummy data that the dependent class needs for its tests and keeps track of methods that the dependent class calls on itself

• The testing framework can then validate that the class interacted properly with the mock class

• Mock objects are so common that there are several frameworks for dynamically creating mock objects in Java

14.1.1 Unit Tests Cont.

• A class that is coded for the purpose of feeding parameters into methods that are being tested is called a test harness

• A test harness class is in essence a manual approach to doing unit testing

• A test harness should be repeatable, that is, data that has already been inputted should be documented

14.1.1 Unit Tests Cont.

public void testGetRoot() // JUnit method

{

double x = 100.0

RootApproximator r = new RootApproximator(x);

assertEquals(10.0, r.getRoot(), .0001);

}

14.1.1 Unit Tests Cont.

public void class TestRootApproximator()

{ . . .

// Test harness class, partial code in main

double x = 100.0

RootApproximator r = new RootApproximator(x);

if (Math.abs(10.0 - r.getRoot()) <= .0001)

System.out.println(“Test case 1 passed”);

}

14.1.2 Providing Test Input

• Crafting test input tests that are repeatable is an key component of program debugging and maintenance efforts

• Being able to repeat a test and validate that the outputs are still correct is important when coding changes are made to a program (regression testing)

• Typically, test data is stored in a file or database

14.1.2 Providing Test Input Cont.

• Positive test cases are test cases that are expected to pass

• Negative test cases are test cases that are expected to fail

• Boundary test cases are test cases that lay right on the boundary of acceptable inputs (0 would be an example if negative numbers not allowed)

14.1.2 Providing Test Input Cont.

• Special test cases are test cases that test situations such as values just to the positive or negative side of a boundary test case, or division by zero, etc.

• A table of test cases should be created prior to testing after doing an analysis of the problem domain; this activity is at least as important as program coding and should precede the coding task!

14.1.3 Test Case Evaluation

• How to determine if an output is correct is a key factor of a testing methodology

• Sometimes an expected output can be calculated by hand

• An expected value might be calculated via code that iterates many times to derive a value

14.1.3 Test Case Evaluation Cont.

• There may be a less efficient way to calculate a value than the approach that is being employed by the method being tested

• This slower but reliable method is called an oracle

• Thus, a test harness class can be written that compares the method output to the results of an oracle

14.1.4 Regression Testing and Test Coverage

• A test suite is a set of tests for repeated testing

• Regression testing involves repeating previously run tests to ensure that known failures of prior versions do not appear in new versions of the software

• White-box testing uses information about the structure of a program

14.1.4 Regression Testing and Test Coverage Cont.

• Black-box testing describes a testing method that does not take the structure of the implementation into account

• Test coverage is a measure of taking into account how many parts of a program have been tested

• For example, you should test every branch of all if/else code

14.1.5 Logging

• Logging is a way of tracing the execution of a program through all the method calls

• More than a useful debugging tool, logging can be a business requirement in many situations

• Consider that all bank transactions should be logged for accounting purposes

14.1.5 Logging Cont.

• However, the most common use for logging is debugging

• A logging API allows a programmer to log messages at various levels of severity, capture the log to a file, and even turn logging on and off entirely

14.1.6 Using a Debugger

• A debugger is a program that you can use to execute another program and analyze its run-time behavior

• You can make effective use of a debugger by mastering just three concepts: breakpoints, single-stepping, and inspecting variables

14.1.6 Using a Debugger Cont.

• When a debugger executes a program, the execution is suspended whenever a breakpoint is reached

• The single-step command executes the program one step at a time

• You should step into a method to check if carries out its job correctly, you should step over it if you know it works correctly

Reference: Big Java 2nd Edition by Cay Horstmann

14.1.1 Unit Tests (section 10.1 in Big Java)14.1.2 Providing Test Input (section 10.2 in Big Java)14.1.3 Test Case Evaluation (section 10.3 in Big Java)14.1.4 Regression Testing and Test Coverage (section 10.4 in Big Java)14.1.5 Logging (section 10.5 in Big Java)14.1.6 Using a Debugger (section 10.6 in Big Java)