Add support for test quick execution

[Duhemm]

I never use it so I completely forgot about it.

Do people actually use it often? If so, we should probably support it since the idea is nice.

[olafurpg]

I've used it in scalameta where we have one project with dozens of test suites. It works great in some cases (for example while editing on test suite) but sometimes not so much.

One somewhat related feature which I find seriously missing in sbt (it works in bazel) is the ability to infer which tests to run from a list of files that have changed. For large projects sbt test can take a long time to run and a lot of the time you only change a couple files in one or two leaf modules. Of course, if your tests rely on escaping the zinc analysis graph then you need to handle this manually, but for most projects I think something fairly basic can get you far.

[jvican]

Yeah, that's something I want so badly. I'd like to implement it, I know how to get it working. I'm assigning this to me, when Mr. @Duhemm is done with the test support I'll get it done.

[jvican]

Upstream ticket I opened some months ago: sbt/zinc#265

[ShaneDelmore]

I use test-only more often but I want to use test-quick, it just doesn't have great change detection.
In my perfect world I want test-quick to run tests in roughly this order:

1. Tests that failed last run
2. New tests
3. Changed tests
4. Tests impacted by changes since last run

Additionally in my beautiful perfect world I then want test to run with the above order, followed by
5. Test suite last time taken to run (in the case parallel testing is enabled, start with slow suites)

[jvican]

I use test-only more often but I want to use test-quick, it just doesn't have great change detection.

I think this is an artifact of sbt's implementation. I believe we could make it work better, following a similar strategy to the one you propose, but that goes against one of my short-term goals in Zinc: remove the API representation altogether and not serialize it in the analysis file.

[dzamlo]

I recently stated using testQuick with sbt. For me, it seems to works correctly.

This is really a time saver. It would be really nice to have that supported in bloop. Especially in combinations with the -w flags. So you can do some modification and have a very quick feedback on whether the tests pass. This would improve the "red-green-refactor" cycle.

[nafg]

What is the current behavior exactly?

[jvican]

I'm re-scoping this issue to only implementing the same test quick functionality people are used to.

[lloydmeta]

I've been exploring bloop for a large-ish Gradle work project recently (hence all the noise), and this is one of those features that I miss from SBT.

[jvican]

@lloydmeta Would be great if you can have a look at it and implement it. I feel like porting the implementation should be reasonably simple.