10.4. Interface Testing

For CDCatalogItemCollection, we create tests based on the interface. The tests should include not only individual method tests, but also tests based on work cases that are derived from the overall system's use cases. These are the four use cases described earlier in this chapter: Search_for_song, Search_by_performer, Search_by_CD_title, and Search_for_availability.

For example, the Search_for_song use case exercises two of the methods in CDCatalogItemCollection. The tests based on this work case will call both search_for_song_by_title( ) to retrieve a number of songs and retrieve_cd_catalog_items_for_song( ) for one or more of the songs.

The tests are written against methods in the interface, not against a particular implementation of an interface. This permits substitution of any implementation during testing. For example, the prototype implementation should pass all the tests for CDCatalogItemCollection. Any real implementation should likewise pass these tests. A web-based implementation would take the search criteria, access a web site that performs CD searches, decode the returned HTML or XML, and place the data into the appropriate fields of CDCatalogItem.[*]

[*] http://Freedb.org/ and http://www.gracenote.com/gn_products/cddb.html both perform searches similar to the ones in our interface. The returned pages from those systems could be parsed for the results.

If a test invoked a method that was particular to a specific implementation, the implementation ...

Get Prefactoring now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.