[Baypiggies] How to determine what unit tests cover a code change?

[Minesh B. Amin]

Bill and Dirk make valid points. 

However, given the scale of your test suite and 
the fact that it takes 5 hours to run seems to imply you 
have a lot of moving parts. I am not sure how
difficult it would be to ensure that everything 
is written in Python, and that "-v" captures the 
sourcing of all files (hence my comment of capturing 
all dependencies, *.py, text, data, other scripts, etc etc).

Now, in terms of parsing the output of "strace", be 
sure to redirect output of your unittest to something 
else ... like

   strace -f -e trace=open \
          /bin/sh -c       \
             "python unittest.py        \
                     2>unittest.stderr  \
                     1>unittest.stdout" \
   2>unittest.strace

   ^^^^^^^^^A^^^^^^^ ^^^^^^^^^B^^^^^^^^

A => stderr        from just strace
B => stderr,stdout from "python ..."


This way, parsing output of strace should be much more 
manageable.

Finally, armed with the dependencies, a build system 
like SCons or Avery Pennarun's "redo" can be tricked 
into skipping over tests for which dependencies have 
not changed. At the end of the day, blow away all 
the computed dependencies, run all tests using strace, 
and recompute the dependencies.

Regards,
Minesh
 

On Wed, 2011-02-02 at 16:19 -0800, Lincoln Peters wrote:
> 
> What I eventually want to do is set up a continuous integration system
> so that the appropriate subset of unit tests is run immediately after
> each code change, and the full suite is run on a less frequent
> interval (maybe once per day).