10.4. Interface Testing

 <  Day Day Up  >  

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 could not be substituted easily. Suppose the test called a method in the web-based implementation to set up an Internet connection. A non-web-based implementation such as the prototype implementation would not have that method, and would cause a compilation or link failure.

To validate the returned information, write a test that compares the results of two different implementations. Not using any implementation-specific methods makes it easy to substitute implementations for comparison.

TEST THE INTERFACE, NOT THE IMPLEMENTATION

Use the contract of the interface to develop the functional tests, not the implementation behind it .


This guideline does not imply that you are prohibited from looking at the implementation to come up with tests that might expose the implementation's weaknesses. That is a form of "white-box" testing. This guideline suggests that you should be able to run the tests you write to attempt to expose those weaknesses, on any implementation, not just on the current implementation.

 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net