CITS5501 Software Testing and Quality Assurance Semester 1, 2022 Workshop 4 (week 5)

1. ISP, graphs and control flow

Consider the following Java method for collapsing sequences of blanks, taken from the StringUtils class of Apache Velocity (http://velocity.apache.org/), version 1.3.1:


/**
* Remove/collapse multiple spaces.
*
* @param String string to remove multiple spaces from.
* @return String
*/

public static String collapseSpaces(String argStr) {
  char last = argStr.charAt(0);
  StringBuffer argBuf = new StringBuffer();

  for (int cIdx = 0 ; cIdx < argStr.length(); cIdx++) {
    char ch = argStr.charAt(cIdx);
    if (ch != ' ' || last != ' ') {
      argBuf.append(ch);
      last = ch;
    }
  }
  return argBuf.toString();
}

Using the ISP principles we have covered in class, suggest some characteristics we could use to partition the argStr parameter.

Once you have several characteristics, consider how you might choose combinations of partitions from them. A recommended approach is to aim for “Base Choice” coverage:

For each characteristic, pick a “base choice” (and explain the reasoning behind that choice)
Select test values for a “base choice” test.
Go through and derive test values for the “non-base” partitions.

Try writing JUnit tests for some of your test values. Compare the characteristics and test values you derived with those of someone else in the same lab. Are your solutions the same?

Using the techniques outlined in the last lecture, try to construct a control flow graph of the method.

How many nodes do you end up with?
How many edges?

You may wish to work with a partner for these exercises, and compare your answers.

For the purposes of this exercise, we’ll take a simplified approach: you may ignore calls to other methods, such as .charAt(), and need only model the control flow within the method. (What about possible exceptions? Should they be modelled, or not? Why?)

A typical way of “labelling” your graph nodes needs is to use letters (“A”, “B”, “C” and so on), and to provide a legend, showing a reader which nodes correspond to which lines (or fragments of lines) of code.

Sometimes there may be multiple nodes representing fragments of code all within the same line (e.g. line 11). As long as you have a clear explanation of what each node represents (e.g. “node D: the line 11 loop condition”) then that’s fine.

Given your test cases from part (a), try mentally or on paper “executing” several tests, and see what paths of the graph get exercised by each of your tests.

How would you subjectively rate the “coverage” of the graph by your tests – good? reasonable? poor?

Work out whether your tests give the following sorts of coverage:

node coverage
edge coverage

What are the prime paths in your graph? What proportion of the prime paths are exercised by the tests you’ve given?

Can you construct some tests which exercise prime paths you haven’t already covered?

2. Test fixtures

class MyClass {
   private int x;
   public MyClass(int x) { this.x = x; }

   @Override
   public boolean equals(Object obj) {
      if (!(obj instanceof MyClass)) return false;
      return ((MyClass) obj).x == this.x;
   }
}

Find the Java library documentation for the equals() method (it’s in the Object class), and read what its requirements are.

In Java, all other classes automatically inherit from the Object class, and may also override methods provided by the Object class – this is what the “@Override” annotation on the equals() method means.

The equals() method should test whether the Object “obj” is “equal to” the receiver object, this, where what “equal to” means is decided on by the implementer of the class. (The equals() method in Java serves the same purpose as the __eq__ special method in Python.) The implementer is free to decide for themselves what “equal to” means for their class.

In order to avoid suprising behaviour for callers of the method, in general equality should be an equivalence relation; for instance, an object should always be equal to itself, and if a.equals(b) is true and b.equals(c) is true, then a.equals(c) should also be true.

The instanceof keyword in Java allows us to check whether an object is an instace of some class (or some class that inherits from that class, directly or indirectly). Normally, implementers of equals will want to return “false” whenever we try to compare with objects not of the same class.

Create a new Java project, create a MyClass.java file containing the code above, and check that it compiles.

import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.AfterEach; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; public class MyClassTest { private MyClass mc1; private MyClass mc2; private MyClass mc3; @BeforeEach public void setUp() { mc1 = new MyClass(3); mc2 = new MyClass(5); mc3 = new MyClass(3); } @Test /* Test the case when, for two objects, the second is null */ public void equalsWhenNullRef() { fail("incomplete"); } @Test /* Test the case when, for two objects, they are not equal */ public void equalsWhenNotEq() {/*...*/} @Test /* Test the case when, for two objects, they are equall */ public void equalsWhenEq() {/*...*/} }

In this case, the instance variables mc1, mc2 and mc3 are potential fixtures for any test.