1

When I'm running gradle build, Gradle compiles my tests and production code. When I run gradle build again, everything is up to date, and nothing is running. All good.

However, when I change a few tests, Gradle doesn't run only the changed tests, but it runs all my tests again. I was hoping that Gradle would be smart enough to find out which tests changed, and only run those test. This would greatly improve the feedback in my test run.

Did I overlook an option, or is my assumption wrong here?

Erik Pragt
  • 13,513
  • 11
  • 58
  • 64
  • 2
    Isn't the entire point of tests to always run them all, to ensure every functionality works? Why would you only want to run tests that have changed since the last time? – nbokmans May 11 '17 at 07:21
  • 1
    Because maybe the only thing I changed was my test. Also, because it could be a long running process. Also, I don't think the SO comment section is the place to discuss this. I'd just like to know if it's possible or not. – Erik Pragt May 11 '17 at 07:25
  • to run single test http://stackoverflow.com/questions/22505533/how-to-run-only-one-test-class-on-gradle so you should manual run your changed test case. – Thang Hoang May 11 '17 at 07:27
  • Thanks @ThangHoang, but that's not really what I meant. Maybe my example is unclear, I'll update it. – Erik Pragt May 11 '17 at 07:31
  • 1st, the test should __know/detect__ which test class has changed, this can be achieved by source version control(such as svn/git) command. 2nd, after got the changed files, you can run the specified test class by gradle command. You could write a shell script to achieve those. – treesong May 11 '17 at 07:33
  • This is how gradle works, it by default runs all tests. – Opal May 11 '17 at 07:33
  • @Opal that's okay, and makes sense. Is there a way to change the default? – Erik Pragt May 11 '17 at 07:39
  • @treesong You don't need source version control to detect changes. You could just make a local hash, I assume incremental compilation does a similar thing. – Erik Pragt May 11 '17 at 07:40
  • 2
    @ErikPragt I guess yes, but _Deep dive into gradle internals_ is ahead of you ;) Not in an easy way as far as I know. – Opal May 11 '17 at 07:42
  • when I continues work on a single test case, that need to change/ re-run, I usually use IDE to run that single test case, it is easy. – Thang Hoang May 11 '17 at 07:51
  • 3
    I think this would be an interesting "feature request". Tests should not be interdependent, so it makes sense, alright, but there could be shared utility code in test classes too, so tests might depend on other code within "test classes". So I guess it would be difficult to implement, just a bit more difficult than what the compiler does when it only recompiles the code that changed and the other pieces of code that depend on it. Also, such a "non-constant" (or "surprising") behavior from Gradle (ie sometimes it runs all tests, sometimes not), could be misunderstood or unwelcome. – Hugues M. May 11 '17 at 07:51
  • @ErikPragt most dev use source version control, it works seamless to find out which file change. or just record the file last modify time, it's a little better than local hash. – treesong May 11 '17 at 08:02
  • @HuguesMoreau, nice input. Basically it would be much easier if gradle decides only if a test should be run (sth has changed) and which tests should be run also - in terms of test dependencies - is left to test runner. – Opal May 11 '17 at 08:02
  • It is not easy to detect tests that should be rerun. A test class that has not changed itself may call a method from another class that has changed. So actually the test should run again, even if it's class did not change. – Henry May 11 '17 at 08:19
  • @treesong doesn't really belong here in the comments, but how would that be better, that's nonsense. The only reliable way is local hash like Gradle does for up-to-date checks. VCS does not make sense, as the question is not what changed since last commit, but what changed since last execution and file modify time also does not work reliably, you can change the file without touching the modify date, or you can change the modify date without changing the content, .... Looking at the content (e. g. with a local hash) is the only reliable way to detect changes in the content. – Vampire May 11 '17 at 08:55

0 Answers0