Test-Driven Reuse: Key to Improving Precision of Search Engines for Software Reuse - Finding Source Code on the Web for Remix and Reuse - page 232

Spreadsheet
+ put(cell:String,value:String):void
+ get(cell:String):String
Fig. 12.1 The interface of a simple spreadsheet component as defined by the test case in List-
ing 12.1
concrete implementation in the next subsection). In step b the required interface of
the desired reuse candidate is extracted from the test case what leads to step c where
a query is derived to drive an arbitrary code search engine (we use our Merobase
search engine that is explained in more detail in Sect. 12.3.1 ). While in principle
it would also be feasible (if not easier) to search and test binary files, our current
implementation still focuses on source code files (because historically there used to
be little support for searching binary files in software search engines) that need to
get compiled against the test case in step d and in case this procedure was successful
are tested in step e.
Fig. 12.2 The test-driven reuse “cycle”
Figure 12.2 furthermore shows that the desired interface from the test case is not
always fully matched by a potential reuse candidate when it comes to compilation
in step d. As a matter of fact, it is not exactly matched in most of the cases so that
the test case will not compile out of the box with most results, which is of course
unsatisfying. As a way out of this dilemma, we have been developing a test-based
adapter [ 11 ] generator that is able to automatically “wrap” the reuse candidate with
the appropriate interface in order to make it compilable and executable. In principle,