1 Source Parsing

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 merely ``an int parameter to method set_address called addr'' will be tomorrow, after the Test Design Tool prompts the test designer for more information, ``an IP Address being set in global variable dest (an 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''.