I write a lot of tests and I've tried this a lot of times (since it can be done with any test framework plus a file watcher on any language) but it doesn't help on my workflow.
The integration with the code editor looks nice as long as it has a way to "jump to the first broken test", and show all the details of the error. I remember when I used to work on c# the test runner of resharper integrated and it was great. My current workflow is, I run the tests in the console and if some test is broken, I search the name of the test across the project to inspect.
Parallel test execution in javascript hasn't worked for me, most of the time I depend on some "state" call it DOM (browser), or call it a test database (node). The fact that I can assume that the runner run one test at the time makes my tests and the before/after code simpler.
Wallaby.js is very different from a file watcher. File watcher would run all of your JavaScript tests and it can be very time consuming. Wallaby uses sophisticated dependency analysis and lots of other tricks to only run tests affected by your code changes, no more no less, so even in large codebases with lots of tests the feedback is delivered very fast.
Yep, wallaby can jump to failing test(s), error sources, show error details inline and much more.
Parallel execution in wallaby works fine with browser "state". Imagine running a half of your tests in one browser tab and another one in a second tab - that's what wallaby does but in 6 or 8 or N processes. As long as your tests set up context for themselves and don't depend on each other (and they shouldn't) - it all works.
I write a lot of tests and I've tried this a lot of times (since it can be done with any test framework plus a file watcher on any language) but it doesn't help on my workflow.
The integration with the code editor looks nice as long as it has a way to "jump to the first broken test", and show all the details of the error. I remember when I used to work on c# the test runner of resharper integrated and it was great. My current workflow is, I run the tests in the console and if some test is broken, I search the name of the test across the project to inspect.
Parallel test execution in javascript hasn't worked for me, most of the time I depend on some "state" call it DOM (browser), or call it a test database (node). The fact that I can assume that the runner run one test at the time makes my tests and the before/after code simpler.