Thanks Tim for feedback. It's a good point that we should have perf tests for this.
@Daz/@Adam thanks for the pointers. I've extracted a fixture that both cpp and java uses. Cheers! On Thu, Apr 3, 2014 at 9:59 PM, Tim Enderling <t.enderl...@intershop.de>wrote: > Hi, > > what we did in a similar test: > > Set the output files read-only after the initial compile. In the positive > test case - where you expect recompilation - expect the IOException. > > Another thought when facing this problem that struck me was: If it is so > hard to test something (like that a file has not been recreated with the > same content) it's a good sign, that it is not an actual requirement and we > should test for something different. Like in case of incremental > recompilation - the requirement is actually speed (which is hard to test > because it is system dependent, but still) no matter how the implementation > achieves it. So if the compiler recompiles every file very fast - who cares > that it touched the files. > > In your case you probably want to test that the last modified timestamp is > not touched, so it doesn't look modified to other heuristics, which you can > only by sleeping or resetting it. > > Just my 2-cents > > Tim Enderling > ------------------------------ > > *Von:* Daz DeBoer [darrell.deb...@gradleware.com] > *Gesendet:* Donnerstag, 3. April 2014 15:11 > *An:* dev@gradle.codehaus.org > *Betreff:* Re: [gradle-dev] avoiding sleeps in incremental compilation > integ tests > > In the native incremental compile tests (1), we're doing an initial > compile, setting the last modified date to '0' for all compiled outputs, > then compiling again. > > We can then check the last modified date to see which files were actually > recompiled. > > > > It's not particularly pretty, but it's working. > > Daz > > > > 1. > org.gradle.nativebinaries.language.cpp.AbstractLanguageIncrementalCompileIntegrationTest > > > > On Thu, Apr 3, 2014 at 4:36 AM, Szczepan Faber < > szczepan.fa...@gradleware.com> wrote: > > Hey, > > > > How do we avoid sleeps in incremental compilation integ tests? My initial > batch of integ tests for java incremental compilation uses Thread.sleep and > file.lastModified to verify which files were actually recompiled. It seems > tricky to avoid the sleep. If I use file hash/size instead of lastModified > it does not work for cases where recompiled class is the same as the > original one. Another option would be to introduce some api/listener that > gets notified just before the compilation and receives the information > about requested source to compile. > > > > Thoughts? > > > > Cheers! > > -- > > Szczepan Faber > > Principal engineer@gradle; Founder@mockito > > Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: > http://www.gradlesummit.com > > > -- Szczepan Faber Principal engineer@gradle; Founder@mockito Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
