May 2014 4 www.drdobbs.com
Contract testing — the testing of specified interfaces and actions
promised in documentation — is crucial to program validation, but
difficult to do on Java classes that extend multiple interfaces.
he Interface Segregation Principle (ISP), which is the
"I" in the list of SOLID coding principles, states that
a client should not rely on interfaces it does not use
(http://is.gd/et4PS6). That is, large interfaces should
be made small enough that clients actually will use
them. ISP therefore implies that an application should have many
small interfaces that are combined to create more-complex ob-
jects. Contract testing holds that the correctness of an application
or component can be assured by producing unit tests, also called
isolated object tests, that validate interface implementations to
ensure that they do not violate the interface contract. There have
been several articles discussing the advantage of this type of test-
ing (see http://is.gd/sUF2cj and http://is.gd/4DQ3Pk); however, I
can find none that addresses how to test the implementation of the
contract when several interfaces are combined in a single object.
Contract tests check the contract that is defined by a Java interface
and associated documentation. The interface defines the method
signatures, while the documentation often expands upon that defini-
tion to specify the behavior the interface is expected to perform. For
example, the Map interface defines put(), get(), and remove().
But the human-readable documentation tells the developer that if
you put() an object, you must be able to get() it unless the
remove() method has been called. That last statement defines
two tests in the contract.
By Claude Warren
Table of Contents