what happend to test-quick?

180 views
Skip to first unread message

drwho

unread,
Aug 3, 2011, 11:03:50 AM8/3/11
to simple-b...@googlegroups.com
what is the replacement for test-quick with sbt 0.10+?

Mark Harrah

unread,
Aug 4, 2011, 9:26:48 PM8/4/11
to simple-b...@googlegroups.com
On Wed, 3 Aug 2011 08:03:50 -0700 (PDT)
drwho <dr_...@xyzzyxyzzy.net> wrote:

> 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

SK

unread,
Feb 13, 2012, 11:13:49 AM2/13/12
to simple-b...@googlegroups.com
To keeps stuff in its right context:

> Feedback that I haven't gotten is: what was it about test-quick that was most helpful?  Was it how it only reran the failed tests, like test-failed, or was it how it reran tests that were recompiled (and hence, one of their transitive dependencies changed)?
> 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.) 
> This is what I mean in that thread by, what is the ideal 'test-quick' going forward.  I'm happy to implement it; I just would like feedback first.

First of all! I'm super thrilled that ~ test-quick might be coming back :D.

To me it meant an incredibly short feedback loop that I could relay on. I've never written so many tests as I did when I used test-quick. I think the quality of my code was better as well and less prudent to failure.

I think it was: how it reran tests that were recompiled (and hence, one of their transitive dependencies changed).

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.)

Please let me know it there is anything I can do to help.

SK

Mark Harrah

unread,
Feb 20, 2012, 8:30:13 PM2/20/12
to simple-b...@googlegroups.com
On 2/13/12, SK <skyt...@gmail.com> wrote:
> To keeps stuff in its right context:
>
>> Feedback that I haven't gotten is: what was it about test-quick that was
> most helpful? Was it how it only reran the failed tests, like test-failed,
> or was it how it reran tests that were recompiled (and hence, one of their
> transitive dependencies changed)?
>> 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.)
>> This is what I mean in that thread by, what is the ideal 'test-quick'
> going forward. I'm happy to implement it; I just would like feedback first.
>
> First of all! I'm super thrilled that ~ test-quick might be coming back :D.
>
> To me it meant an incredibly short feedback loop that I could relay on.
> I've never written so many tests as I did when I used test-quick. I think
> the quality of my code was better as well and less prudent to failure.
>
> I think it was: how it reran tests that were recompiled (and hence, one of
> their transitive dependencies changed).

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*
> *
>

Daniel Sobral

unread,
Feb 21, 2012, 9:29:38 AM2/21/12
to simple-b...@googlegroups.com
On Mon, Feb 20, 2012 at 23:30, Mark Harrah <dmha...@gmail.com> wrote:
>> 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?

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.

Stein Kåre Skytteren

unread,
Feb 22, 2012, 1:31:05 AM2/22/12
to simple-build-tool
I agree with Daniel that transitive dependencies would be the best. It
might be a bit slower but I guess it is worth it.

Btw: I like that it's not just me thinking this feature is usefull.

SK

On Feb 21, 3:29 pm, Daniel Sobral <dcsob...@gmail.com> wrote:

Eugene Vigdorchik

unread,
Feb 23, 2012, 2:05:34 PM2/23/12
to simple-b...@googlegroups.com
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?


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.
>

Mark Harrah

unread,
Feb 25, 2012, 11:38:48 AM2/25/12
to simple-b...@googlegroups.com
On Thu, 23 Feb 2012 23:05:34 +0400
Eugene Vigdorchik <eugene.v...@gmail.com> wrote:

> 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

Mark Harrah

unread,
Feb 25, 2012, 11:40:10 AM2/25/12
to simple-b...@googlegroups.com
On Tue, 21 Feb 2012 22:31:05 -0800 (PST)
Stein Kåre Skytteren <skyt...@gmail.com> wrote:

> 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

Reply all
Reply to author
Forward
0 new messages