On this page:
Overview of the tests the programmer can design
Designing test cases - a brief overview
Reporting of the results
Version: 5.2.1

User’s Guide - Overview

Overview of the tests the programmer can design

The tester package supports the design of tests for a program that consists of a collection of multiple classes and interfaces. A typical test suite consists of sample data for each class in the class hierarchy followed by the unit tests for every method in every class in the class hierarchy. The class where the tests are defined (typically called the Examples class) represents the client for the defined class hierarchy. By being defined in the same package, it has access to the package-protected methods and fields.

The tests are designed to check whether the given actual value is the same as the expected value, comparing the objects for extensional equality. The comparison of two instances of objects in the same class is based on comparing the values of the corresponding fields. For complex data this comparison is replicated for each field that is an instance of another class.

The comparison of inexact values requires that the programmer invokes the checkInexact... variant of the test method and supplies the desired relative TOLERANCE. Otherwise, the exact test will fail if any field within the class contains an inexact value (i.e. a value of the type double or float) or their wrapper classes, and the comparison does not yield an exact true result (e.g. 5.0 == 5.0 succeeds while 5.0 == 10.0/2.0 fails).

Absolute tolerance is used when comparing an inexact value with a double or a float value that represents exact zero.

There is a support for comparing inexact numerical values, wrapper classes, for testing whether a method invocation, or a constructor invocation threw the desired Exception, and for tests where the programmer defines the meaning of equality for one class within the class hierarchy, or for any two objects.

For data collections that implement the Iterable interface the elements of the structure are compared pairwise. This is done by default for the Java Collections Framework classes, but ihas to be invoked explicitly for the user-defined classes that implement the Iterable interface.

The design of tests for data collections that implement the Map interface again compares the values of the two collections.

Tests that determine whether the actual value is one of several possible values are also supported, as are tests for checking whether the actual value is within the given range of values, using either Comparable implementation to verify in-range property for the given actual, or using the given Comparator object.

_________________________________________________________________________________

Designing test cases - a brief overview

The following Examples class definition provides a simple preview of how the tests are written using the tester package:

import tester.*;

 

class Examples{

 Examples(){}

 

 Flight bos_phi = new Flight("BOS", "PHI",  8, 10);

 Flight phi_hst = new Flight("PHI", "HST", 11, 13);

 Flight hst_sfo = new Flight("HST", "SFO", 14, 15);

 Flight dfw_sfo = new Flight("DFW", "SFO", 14, 15);

 

 ILoF bos_sfo = new Flight("BOS", "SFO",  9, 14);

 ILoF bos_sfo_3 = new ConsLoF(this.bos_phi,

                   new ConsLoF(this.phi_hst, this.hst_sfo));

 ILoF bos_sfo_err = new ConsLoF(this.bos_phi,

                     new ConsLoF(this.phi_hst, this.dfw_sfo));

 

 // test the method departsFrom for flight itinerary classes

 boolean testDepartsFrom(Tester t){

     return

          t.checkExpect(bos_phi.departsFrom(), "BOS")  &&

          t.checkExpect(phi_hst.departsFrom(), "PHI");

 }

 

 // test the method departsAfter for flight itinerary classes

 void testDepartsAfter(Tester t){

     t.checkExpect(bos_phi.departsAfter(7), true);

     t.checkExpect(bos_phi.departsAfter(8), false);}

 

 // test the method connectsTo for flight itinerary classes

 void testConnectsTo(Tester t){

     t.checkExpect(bos_phi.connectsTo(bos_sfo_3), this.phi_hst);

     t.checkExpect(bos_phi.connectsTo(bos_sfo), null);

 }

}

An instance of the Tester class invokes the test... methods. This instance is a parameter for the method that invokes the tests. As long as the name of the method starts with the test and consumes one argument of the type Tester the tester package will evaluate the test cases defined within and record the results of the tests. The return type for the test method should be either boolean or void.

The imperative style where the return type for the test method is void is the preferred way of writing test cases, as it guarantees that every test will be performed.

The alternative style where the return type is boolean is provided to support the purely functional programming style used in the early parts of our curriculum. Here the result of the test method is a conjunction of the results of several test cases. In this setting once a test case fails, the remaining test cases within this conjunction are not evaluated. We encourage the user to group together tests for every method, so that a failed result for one method does not affect the test results for other methods.

All test methods allow the user to supply an optional String argument that describes this test. When provided, this String is shown in the test report.

_________________________________________________________________________________

Reporting of the results

Once the tests have been run the tester package prints first the values of all fields defined in the Examples class, followed by the report of the test results.

Please see the section Running Tests for other options for reporting the results.

A typical report would be:

Tester Prima v.1.5.1 - 17 June 2012

-----------------------------------

Tests defined in the class: SimpleExamples:

---------------------------

SimpleExamples:

---------------

 

   new SimpleExamples:1(

    this.hello =  "hello"

    this.world =  "world"

    this.n = 5)

------------------------------

Found 1 test method

 

Ran 3 tests.

All tests passed.

 

Test results:

--------------

 

--- END OF TEST RESULTS ---

or, if errors have been detected the report prints both the actual and the expected value for that test and includes a link to the relevant line in the test suite:

Tester Prima v.1.5.1 - 17 June 2012

-----------------------------------

Tests defined in the class: SimpleExamples:

---------------------------

SimpleExamples:

---------------

 

   new SimpleExamples:1(

    this.hello =  "hello"

    this.world =  "world"

    this.n = 5)

---------------

Found 1 test methods

 

Ran 4 tests.

1 test failed.

 

Test results:

--------------

 

Error in test number 4

will fail

tester.ErrorReport: Error trace:

        at SimpleExamples.testStrings(SimpleExamples.java:12)

 

actual:                                 expected:

"hello"................................. "world"

 

--- END OF TEST RESULTS ---

The test report shows the number of test that have been performed, the number of tests that failed, and for every failed test it shows both the actual and the expected values, and provides a link to the place where the failed test is located.

Additionally, the report can include a pretty-printed display of all data that have been defined as fields of the Examples class. The programmer can also access directly the code that produces a toString like representation of any object, and also provide own method that will be used for pretty-printing the values of any class.

If the user implements toString method, the tester will report the values of the instance of this class twice, first by invoking the toString method, then by generating the standard pretty-printed value.

If the value of an instance is a field of another object, the pretty-printed value needs to be indented. For example:

Book b =

 new Book:1(

 this.title =  "My Book"

 this.author =

  new Author:2(

  this.name = "Famous Author"))

If the programmer desires to control the pretty-printing of the values of a particular class, he can implement the method toIndentedString(String indent) that will produce a String with the lines indented by the given indent. In that case all reports generated by the tester library will invoke this method to display the values for any instance of this class. The value of the indent when the tester invokes the method will always be just a relevant number of spaces.