6 ms·

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 impa

by _cfl0 4y ago

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.

volkk 4y ago
> 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 4y ago
  The second part is the aim here. This is more of a code watcher than a test watcher specifically.
  - volkk 4y ago
    very cool!
  - funcDropShadow 4y ago
    sbt ~test uses the dependency analysis of the scala compiler to determine which tests to run.
    - lupire 4y ago
      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 https://www.scala-sbt.org/1.x/docs/Testing.html
Cthulhu_ 4y ago
> 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 https://nx.dev/concepts/affected)
- lupire 4y ago
  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 4y ago
    10.
- _cfl0 4y ago
  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.

by _cfl0 4y ago

volkk 4y ago

> 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 4y ago
The second part is the aim here. This is more of a code watcher than a test watcher specifically.
- volkk 4y ago
  very cool!
- funcDropShadow 4y ago
  sbt ~test uses the dependency analysis of the scala compiler to determine which tests to run.
  - lupire 4y ago
    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 https://www.scala-sbt.org/1.x/docs/Testing.html

Cthulhu_ 4y ago

> 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 https://nx.dev/concepts/affected)

lupire 4y ago
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 4y ago
  10.
_cfl0 4y ago
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.