Unit tests are not just about testing [1]. A unit test is a piece of code that executes a part of a program (the unit) and checks to see if it worked. Therefore, the test documents a way to use the unit. Two teams (at least) are independently exploring ways to use this information.

This paper shows how a tool (MathFinder) can use unit tests to help a programmer select a math library suitable for an algorithm. Once selected, the tool proposes detailed code for the algorithm using the library’s application programming interface (API). The paper describes experiments that show how a typical maintenance project within a Java/JUnit/Eclipse plus Scilab environment is done faster when programmers use MathFinder. The results may generalize to other environments. The key idea is to specify requirements as unit tests for a very high-level interpreted language, and secondly, as queries to search an index of unit tests in a lower-level language plus API. MathFinder acts as a partial compiler and produces a list of possible sequences of function calls that pass the tests. Apparently, 90 percent of the time the top of the list is a suitable piece of code to implement the given algorithm.

This is a typical research paper in the software engineering field and will interest fellow researchers. Meanwhile, a quarter of the way round the world, another team [2] (not referred to here) is also starting to mine unit tests to recommend code to programmers.