Atlassian's Clover product does this. On 16/10/2010, at 12:48 AM, Steve Ebersole <[email protected]> wrote:
> I seem to recall a recent discussion about this very thing, though leveraging > either code coverage tools or the same underlying bytecode inspection. The > idea being the ability to know wat tests touched which code and rerunning > said > tests only when there were changes to classes they touched. > > On Thursday, October 14, 2010, at 06:03 pm, Peter Niederwieser wrote: >> Hi all, >> >> just a quick thought on extending Gradle's incremental build capabilities >> to the test runner. Interested in your opinions. >> >> The basic idea is to provide a way to only run test classes which are >> likely affected by recent code changes. I can think of two ways to >> determine which test classes should be run: 1. Only run a test class if >> its subject(s) have changed. For this we'd need a way to specify what a >> test's subject(s) are. Spock has a @Subject annotation for this. 2. Only >> run a test class if one of the classes it (transitively) depends on has >> changed. This might be costly to compute (not sure). >> >> Both strategies bear the risk that a test class won't be run although a >> change was made that affects the outcome of the test (e.g. when dependency >> injection is used or when a non-code file is changed). Do you think an >> incremental test runner could still be useful, or should we always play it >> safe and run all tests in a project (possibly in a smart order to reduce >> average time until a test fails)? Maybe incremental test running should be >> left to IDEs (for continuous testing)? >> >> Cheers, >> Peter >> >> PS: Had problems to post to this list. Nabble didn't work, and neither did >> e-mail (although I'm subscribed to this list in Xircles). Hopefully it >> will work this time (after unsubscribing and resubscribing). > > --- > Steve Ebersole <[email protected]> > http://hibernate.org > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
