> what is the replacement for test-quick with sbt 0.10+?
The implementation of test-quick was heavily based on the old compilation strategy. It ran tests that had been recompiled since their last success.
If I didn't mention it already, I am interested to know what people want for a test-quick in 0.10. What is the ideal test runner?
-Mark
Thanks for the feedback.
> I think you are right in your assumption: In sbt 0.10+, a test source file
> (like normal source files) is only recompiled if the API of a direct
> dependency changes. Is this the better trigger? I think not by default,
> but perhaps a switch would be useful. To replicate 0.7 behavior,
> test-quick would have to do extra work beyond that done by 'compile'.
> (This might be fine, I just don't want to do it if it isn't useful.)
Sorry, I'm not sure which one you think should be the default?
1. An API change to a direct dependency triggers running the test?
2. Any transitive dependency triggers running the test?
-Mark
> Please let me know it there is anything I can do to help.
>
> SK*
> *
>
I don't know about him, but I'm keen on the latter. I have always done
full testing because I wasn't aware such an option as transitive
dependency testing might be available.
--
Daniel C. Sobral
I travel to the future all the time.
Eugene.
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To post to this group, send email to simple-b...@googlegroups.com.
> To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
>
> I also agree here: any transitive dependency change would trigger the test run.
> Does it provide full test run successful if test-quick successful guarantee?
If I understand what you are asking, test-quick and test are separate tasks, just like test-only and test are separate. test-quick would be an input task like test-only.
-Mark
> I agree with Daniel that transitive dependencies would be the best. It
> might be a bit slower but I guess it is worth it.
Ok, thanks.
-Mark