PinDown is easy to integrate into the customer’s regression test system. Typically the customer has an advanced script which kicks off the entire regression test suite on a computer farm. That script does not need to change in any way and those tests does not need to be defined anywhere in the PinDown database.


 Fig 1. PinDown System 

There are two integration steps that needs to be done to make PinDown debug the customer’s test failures. First the customer needs to tell PinDown about the structure of the results that is the output from regression script. Are the test names and results available in a simulator generated log files? Or is there a summary somewhere which summarizes the test failures? PinDown has a command called extract which can do anything  a Unix sed command or grep can do and it supports regular expressions. Using extraction commands you specify for PinDown the relative paths to logs, directory names, web pages where the test names, configuration names, compilation results, test names, times and results can be extracted by PinDown.

The second integration step is for PinDown to be able to kick off an individual test for a specific seed number and maybe a specific build configuration. The customer must supply a number of scriptable steps so that PinDown during debug can kick off a test it wishes to debug. These steps are not unique to PinDown; it is the same steps that an engineer will do during manual debug in order to reproduce a specific failure.

PinDown also needs to be setup to connect to the revision control system, it’s own SQL database and the email server. These are simple setup commands that do not change very often. It is possible to specify exactly which sub-repositories and sub-folders which PinDown should track for each project in order to minimize the amount of changes it tracks to those relevant for a particular project.