22 ms·
If the time taken to run the test suite is so critical, then how is the "winning" result of 7m55s any better? In my experience any multi-minute operation invit
by underwater 8y ago
If the time taken to run the test suite is so critical, then how is the "winning" result of 7m55s any better?
In my experience any multi-minute operation invites a context switch or coffee break, and end up being roughly equivalent in practice.
- sams99 8y agoI completely understand the concern here. If every change required an 8 minute wait it would be real sad for us. We use a tool called `rake autospec` at Discourse which is a smart test runner. I personally like the vim integration we built. The way it works... 1. Run `bin/rake autospec` in a terminal 2. I head to the code I want to change, I change the code 3. The spec runner figures out what the right test is run and runs that. 4. While it is busy running specs at any time it can be interrupted by saving a "*.spec" file in which case the spec runner will run the spec at the cursor This has worked wonderfully well for us.
- majewsky 8y agoFYI, list formatting works best when you leave an empty line between each item. 1. just 2. like 3. this
- ufmace 8y agoThat's exactly what I thought - a 50% faster test suite run is nice I guess, but they're all still way too slow to be running all the time. I'll run the tests in 1 file or subset of files or rspec describe block or something that's relevant to what I'm doing and finishes in <10s. Save the multi-minute full runs for CI or big changes where you have no idea what will happen.