This sounds a lot like a couple of old JUnit test runners: InfiniTest - https://infinitest.github.io/ an d https://infinitest.github.io/doc/intellij#how-it-works JUnit Max - https://web.archive.org/web/20090206151635/http://www.threer... partially surviving as https://junit.org/junit4/javadoc/4.12/org/junit/experimental... Ruby has something similar: autotest - https://github.com/grosser/autotest I think it's a good…
Show HN: I built a tool to get instant test results
41–50 of 68 posts
Re: Show HN: I built a tool to get instant test results
#42I'm a bit confused how this differs from the existing watch modes that are built into test runners I'm familiar with, such as Jest. Is this something that I'm used to in TypeScript, but which just doesn't exist in most language's ecosystems?
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.
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)
Re: Show HN: I built a tool to get instant test results
#43Re: Show HN: I built a tool to get instant test results
#44Earlier quoted context omitted.
> 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?
The second part is the aim here. This is more of a code watcher than a test watcher specifically.
Re: Show HN: I built a tool to get instant test results
#45Re: Show HN: I built a tool to get instant test results
#46Earlier quoted context omitted.
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.
> 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 )
How many tests will your system run? That's the important question.
Re: Show HN: I built a tool to get instant test results
#47Earlier quoted context omitted.
The second part is the aim here. This is more of a code watcher than a test watcher specifically.
sbt ~test uses the dependency analysis of the scala compiler to determine which tests to run.
Re: Show HN: I built a tool to get instant test results
#48This sounds a lot like a couple of old JUnit test runners: InfiniTest - https://infinitest.github.io/ an d https://infinitest.github.io/doc/intellij#how-it-works JUnit Max - https://web.archive.org/web/20090206151635/http://www.threer... partially surviving as https://junit.org/junit4/javadoc/4.12/org/junit/experimental... Ruby has something similar: autotest - https://github.com/grosser/autotest I think it's a good…
Jest, probably the most popular JS test runner of today, also has had it since forever.
Re: Show HN: I built a tool to get instant test results
#49I like the concept and it seems that "run them all and see what changed" is a great model to avoid missing any side effects from a code change. However, if you're running all the tests on every change, doesn't that mean the responsiveness is necessarily greater than 250ms if your test suite is longer than 250ms? Regardless, running tests in the background to eliminate human delay is good. It would be nice if the (~te…
This tool doesn't run all the tests, only the ones affected by the code changes since the last run. It figures out which tests to run by initially running all tests, and storing the code coverage of each test. It doesn't need to rely on "test change likelihood" - if a code change is outside of the code coverage of the test, it doesn't affect the test.
This assertion questionable, the extent it is true it is language specific.
Here is a counterexample in Java:
// foo.java
public class Foo {
public static final int LENGTH = 10;
}
// bar.java
public class Bar {
public int getFooLength() {
return Foo.LENGTH;
}
}
Code coverage tools will not highlight Foo as being touched when Bar.getFooLength is invoked, even though a test asserting that getFooLength() is 10 will fail or succeed depending on Foo.LENGTH. The reason for this is that Foo.LENGTH is inlined in Bar. If you for example wanted to patch a new version of the value, you need to supply Bar.class to affect the change; patching Foo alone would do nothing.C and C++ likewise do not satisfy this requirement because macros.
Re: Show HN: I built a tool to get instant test results
#50Can you cache the coverage DB so this can be run in a CI pipeline?