11–20 of 68 posts
For folks using bazel, there is also [bazel-watcher][1]. Also worth checking out [watchman][2] for this style of workflow in general. [1]: https://github.com/bazelbuild/bazel-watcher [2]: https://facebook.github.io/watchman/
2. How does it detect what tests need to be re-run when a given file changes?
Though I understand the intent, I think it has the risk to run into a run-hack-run-hack programming style.
I'm currently reading Code Complete which advises against this practice. Instead, one should strive to write code that works from the start instead of hoping it to work eventually.
For folks using bazel, there is also [bazel-watcher][1]. Also worth checking out [watchman][2] for this style of workflow in general. [1]: https://github.com/bazelbuild/bazel-watcher [2]: https://facebook.github.io/watchman/
Bazel is awesome, it just runs way too many tests to be fast enough
Bazel (and bazel watcher) really shines when you have lots of small packages.
Slow is smooth, smooth is fast. Though I understand the intent, I think it has the risk to run into a run-hack-run-hack programming style. I'm currently reading Code Complete which advises against this practice. Instead, one should strive to write code that works from the start instead of hoping it to work eventually.
I use it as I would run tests through a terminal normally. Built this because I hate running tests.
I 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…
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.
while [ 1 ]; do inotifywait .{c,h} t/.{c,h}; make && make check ; done
1. Does this mean I have to disable IDE autosave so it doesn't attempt to run tests when the project is in an intermediate, invalid state? 2. How does it detect what tests need to be re-run when a given file changes?
2. The first run and every subsequent one collects code coverage which is saved in an sqlite db. Every file change is compared to the code coverage.
Although this approach isnt perfect, The idea here is being fast. I always rerun the entire suite just before committing the code.
I 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…
If I would get a break from hn comments I could finish it today lol ;)