CITS5501 lab 2 – Data-driven tests and test design

1. Parameterized tests

Normal test methods in JUnit don’t take any parameters at all – for instance, the testAdd method from last week’s code:

  @Test
  public void testAdd() {
      Calculator c = new Calculator(3, 4);
      int result = c.add();
      assertEquals(result, 7, "result should be 7");
  }

But in last week’s lab, we briefly saw an example of a parameterized test in JUnit – these do take parameters. The parameterized test was addZeroHasNoEffect, which checks, for a range of int values, that using the Calculator to add 0 to the number gives back the original int:

  /** Adding zero to a number should always
    * give us the same number back.
    */
  @ParameterizedTest
  @ValueSource( ints = { -99, -1, 0, 1, 2, 101, 337  })
  void addZeroHasNoEffect(int num) {
      Calculator c = new Calculator(num, 0);
      int result = c.add();
      assertEquals(result, num, "result should be same as num");
  }

What do the @ParameterizedTest and @ValueSource annotations on this test method mean?

Adding the @ParameterizedTest tells JUnit that this test needs to be run in a special way. In effect, this annotation tells JUnit: “You need to call this test multiple times. Each time you should call it with a different int.” Where does Junit get the ints from? We supplied a @ValueSource annotation which tells JUnit “Here is the list of ints to use with the test”. (But there are other ways of supplying the list of ints besides writing them out explicitly as we’ve done here – you could put them in a .csv text file, or write a special method that returns a “stream” of ints.¹)

So to summarize: the test method, addZeroHasNoEffect, takes one parameter, an int, and each time the method is called, it is passed a different int from the list given by @ValueSource.

The code for this week’s lab is the same as last week’s, but with some new test methods, so you can try out the addZeroHasNoEffect test if you haven’t already:

Hopefully the use of @ValueSource seems straightforward. But a question may now arise: the addZeroHasNoEffect(int num) test method takes only one parameter, but what if we were working with a method that took two parameters (a String and an int, say). Or what if we wish to specify not just the test values, but also the expected values (a very common situation)? How could we supply multiple sets of parameters in that case?

Below is an example of such a method with multiple parameters. It’s taken from this week’s code, which includes an additional test method when compared with last week’s: tableOfTests(). The tableOfTests() method is another parameterized test; it draws its test values and expected values from a method called additionTestCasesProvider():

  @ParameterizedTest
  @MethodSource("additionTestCasesProvider")
  /** Test Calculator.add() with multiple test values
   * and expected values.
   *
   * @param num1 First test value to be passed to Calculator.add()
   * @param num1 Second test value to be passed to Calculator.add()
   * @param expectedResult The expected result for Calculator.add()
   */
  void tableOfTests(int num1, int num2, int expectedResult) {
      Calculator c = new Calculator(num1, num2);
      int result = c.add();
      assertEquals(expectedResult, result, "result should be same as as expected result");
  }

In the previous example, we used the @ValueSource annotation, which is used when you have a straightforward list of literal values you want JUnit to iterate over. But in tableOfTests, we’re using a new annotation, @MethodSource. If we annotate our test method with @MethodSource("additionTestCasesProvider"), we are saying to JUnit, “Go and call the additionTestCasesProvider method in order to get a list of test values and expected values”. You can read more about MethodSources in the JUnit documentation on writing parameterized tests.

This sort of testing is called data-driven testing – we have basically the same test being run, but with different values each time; so it makes sense to write the logic for the test just once (rather than four times).²

Let’s look at the additionTestCasesProvider() method which supplies the parameters used by tableOfTests(). The additionTestCasesProvider() method uses Java’s Stream API, introduced in Java 8. For the moment, you don’t need to know the details of how the Stream API works – just that it when used with JUnit, it gives us a convenient way of constructing “lists of lists”. In the code below, the arguments() method will take any number of arguments we like (here, three ints, comprising two test values and an expected value) and group them together into a list-like object (Arguments); and the Stream.of() method will take any number of Arguments objects we like, and group those together in a list-like object (of type Stream<Arguments>):

  static Stream<Arguments> additionTestCasesProvider() {
      return Stream.of(
          // the arguments are:
          //    num1, num2, and expected result.
          arguments(1, 2, 3),
          arguments(3, 7, 10),
          arguments(3, 7, 11)
          arguments(99, 1, 100)
      );
  }

2. Preconditions and postconditions

Work through and discuss the following scenario and exercises in pairs or groups of three if there is sufficient time. If there is not, work through these in your own time.

Consider the following scenario:

/** Remove a unit from the system
 */
void removeUnit(String unitCode) {
  units.removeRecord(unitCode);
}

If possible, it’s recommended you discuss the following questions with a partner or in a small group, and come up with an answer for each. But if that is not feasible, spend several minutes thinking about the questions yourself before sharing ideas with the class.

3. Testability

Consider the following, each of which is supposed to be a requirement or specification. Discuss with a partner – do you think it would be straightforward to write tests for them? If not, why not?

1. The flight booking system should be easy for travel agents to use.
2. The int String.indexOf(char ch) method should return a -1 if ch does not appear in the receiver string, or the index at which it appears, if it does.
3. Internet-aware Toast-O-Matic toasters should have a mean time between failure of 6 months.