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
