Issue link:

Contents of this Issue


Page 3 of 24

May 2014 4 Simplifying Contract Testing 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. T 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 ( 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 and; 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 [ TESTING ] Table of Contents Previous Next Previous Next Download Download Register Register Subscribe Subscribe Previous Next Previous Next

Articles in this issue

Links on this page

view archives of InformationWeek - 423_DrDobbs