[_cfl0]

Well, I would say the biggest difference is while the watch mode you described runs all the tests for every change.

hypertest only runs the tests the were impacted by the changed code. Resulting is blazing fast performance.

I’d say it’s even fast than apples alt+tab animation most of the time.

[Cthulhu_]

> Well, I would say the biggest difference is while the watch mode you described runs all the tests for every change.

This is not true though. Might depend on the test tooling used, but most of the ones I've used only run changed tests (either directly or through change detection via git, e.g. https://nx.dev/concepts/affected)

[lupire]

Let's say you have 100 tests that depend on the file being changed, but only 10 that depend on the method or line changed since last year run.

How many tests will your system run? That's the important question.

[_cfl0]

10.

[_cfl0]

Nx is even clealry different. It isn’t run on every code change, but on commits.

You can’t use it live, And also the analysis granularity is just way too wide compared to this.

[volkk]

> hypertest only runs the tests the were impacted by the changed code

with all due respect, this is also a solved problem with test watchers. unless you mean this is smart enough to not just run unit tests that are directly related to the file changed, but also understands code changes from the perspective of downstream dependencies?

[_cfl0]

The second part is the aim here.

This is more of a code watcher than a test watcher specifically.

[funcDropShadow]

sbt ~test uses the dependency analysis of the scala compiler to determine which tests to run.

[lupire]

Are you sure that's actually true, all the way down to the method or line level?

https://www.scala-sbt.org/1.x/docs/Testing.html

[volkk]

very cool!