CITS5501 lab 3 (week 4) – ISP

1. Test coverage concepts

Suppose you are asked to write tests for a Java method in the AgePricing class, whose Javadoc and signature are as follows:

/** Returns true if age is eligible for adult ticket price.
 *
 * @arg age The age of the customer
 * @return true if someone of that age is eligible for the adult ticket price,
 *         false otherwise.
 */
public static boolean isAdult(int age);

Elsewhere in the API documentation, you’re told that any person who is 18 or over is considered an adult.

Suppose also you’re given the following JUnit test for this method. (There’s no need to compile and run it, but you’re welcome to do so if you want.)

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class AgePricingTest {

  @Test
  void adultAgeShouldReturnTrue() {
    assertTrue(AgePricing.isAdult(30));
  }
}

The above test is the only test currently in place, and we aren’t given access to the implementation.

Question

Is this one test enough to be confident that the method works? If not, come up with additional test cases.¹ Think about:

• What are all the different “kinds” of ages we might need to check?
• Are there any special or edge values?
• What’s just inside or just outside the adult cut-off?
• Are there unusual but possible inputs?

In lectures, we’ve mentioned that Java code can be instrumented so that, after your tests run, a coverage tool can report which lines of implementation code were executed. One such tool is JaCoCo (Java Code Coverage), which integrates with build systems and IDEs to produce coverage reports: https://www.jacoco.org/jacoco/.

Suppose we now are given access to the implementation of the isAdult(int age) method (feel free to suggest a plausible one). We instrument the method, and run the original single-test suite, then later your improved multi-test suite.

Question

Do you think the reported line coverage will change between the two suites? Why or why not? If the reported coverage doesn’t change, what does that tell you about the limitations of line coverage as a measure of how thoroughly a method has been tested?

2. Binary search

Consider the Javadoc documentation and signature for the following Java method, which searches inside an array of chars for a particular value.

(Adapted from the Android version of the Java standard library.)

/**
 * Performs a binary search for @code value in the ascending sorted
 * array @code array, in the range specified by fromIndex (inclusive)
 * and toIndex (exclusive).  Searching in an unsorted array has an
 * undefined result. It's also undefined which element is found if there
 * are multiple occurrences of the same element.
 *
 * @param array the sorted array to search.
 * @param startIndex the inclusive start index.
 * @param endIndex the exclusive start index.
 * @param value the element to find.
 * @return the non-negative index of the element, or a negative index
 *         which is <code>-index - 1</code> where the element would be
 *         inserted.
 * @throws IllegalArgumentException if <code>startIndex > endIndex</code>
 * @throws ArrayIndexOutOfBoundsException if
 *         <code>startIndex < 0 || endIndex > array.length</code>
 * @since 1.6
 */
public static int binarySearch(char[] array, int startIndex, int endIndex, char value)

Based on the prescribed reading, discuss how you would go about creating tests using Input Space Partitioning.

1. What steps are involved in doing ISP?
2. What is the input domain here?
3. What are some characteristics you could use? (You may wish to drop in on a timetabled lab session and compare with another student to see what characteristics they have come up with. Remember to make sure each characteristic does in fact give you a partitioning.)

Once you’ve answered these questions, you might like to try implementing some of your tests in Java using JUnit.

3. Stack class

Suppose we have a Stack class that is intended to implement the stack abstract data type. The class stores ints, and provides methods for observing the state of the stack, and for performing the “push” and “pop” operations. The method signatures for the class are as follows:

• public IntStack ();
• public void push (int i);
• public int pop (); /** Throws an exception if empty */
• public boolean isEmpty()

Assume the object state consists of an int array.

1. If we wanted to model push as a function, what sort of function would we use? How about pop?
2. Identify all the parameters for the pop method, and suggest some characteristics that can be used to partition the input space.

4. Further questions

Consider the following questions about ISP and try writing an answer to each. (Questions like this are typical of ones you might be asked in the mid-semester test or final exam.) Once you’ve made an attempt, you might like to drop in on a timetabled lab session to compare your answers with other students’.

There is not necessarily any single correct answer to such questions; students are expected to base their answers on the information covered in class and in previous units, and on reasonable deductions they can make from those.

1. Suppose we need to test some method (let’s suppose it is a static method myMethod that takes one int for the sake of argument, and that it’s sensible to partition it into positive, negative and 0-valued ints. i.e. the signature is static myMethod(int i)).

   Suppose you’ve already written three tests for the function; each of your 3 tests uses a test value from one partition.

   Your supervisor says three tests is not enough, and you should write more. What do you think? Would more tests be better? Could more tests be worse?

2. Research suggests that the later in the development life cycle a fault is discovered, the more expensive it is to fix. Why do you think this is so?