Interfaces

For languages that syntactically support interfaces, the published interfaces are usually the best place to start. In addition to typically being documented, they tend to be the least coupled to other modules. They also have a high degree of stability over time, minimizing the effects of whatever coupling cannot be avoided.

In an object-oriented context, you would use the API published via features like Java’s or C#’s interfaces or in C++ class headers. Procedural or functional languages might use function prototypes and signature declarations. Regardless, using the published API specification—even when testing implementations—helps to constrain your usage to the most stable portion of the specification. Even an unpublished, internal-use interface will tend to be more stable than an implementation.

Note that in a procedural or functional context, constructs like function prototypes and signatures fill the same role as object-oriented interfaces. Strictly typed languages like C provide stronger bindings and guarantees than the more flexible declarations in dynamic languages like Perl or JavaScript, but wide usage of loosely enforced interfaces still provide relatively strong guarantees of stability and compatibility for use in tests. For example, there is little need to question the jQuery event object’s contents or to wonder how it will be passed to jQuery event handlers.

Regardless of the programming model in which you are working, you should favor use of the interface definition in your tests to the greatest extent possible when verifying implementations. This has the dual purpose of minimizing the coupling of your tests and helping to verify that your code meets the contract of the interfaces it implements.