With modern languages, lexical and syntactic analysis tools, and compiler suites, it is relatively straightforward to build tools to parse source code and walk ASTs, looking for ``juicy bits''. The Clue Extractor will do so, looking for:
Armed with these finds, the Clue Extractor will look at a most basic level in the test catalog for ``simple'' tests, idioms, and references to suggest.
So as not to impose too much burden on a shop's coding style, the Clue Extractor's source parsing modules will be highly configurable, allowing immense variation in naming idioms, coding styles, and so forth. For example, a shop that has a rigid rule about using Hungarian Notation and naming variables and methods with strict relationship to their purpose and interaction will be able to customize the Clue Extractor to find richer semantic content than a shop with haphazard or uncoordinated coding standards. However, the uncoordinated shop will still find benefit in the Clue Extractor's basic ability to point out tests based on data type and code idioms common to the language.
Furthermore, the Clue Extractor's interaction with the Test Design
Tool will allow the uncoordinated shop to iteratively refine the Clue
Extractor's knowledge of their codebase. What is on today's test run
int parameter to method
addr'' will be tomorrow, after the Test Design Tool prompts the
test designer for more information, ``an
IP Address being set
in global variable
int) by being passed as an
int to the method
set_address'', and will therefore
prompt the Test Design Tool to suggest a much richer set of possible
testing idioms based on its ``IP Addressness''.