mini reporter should surface failures faster.

[jamestalmage]

From #618 (comment)

For most test suites, the mini reporter just spits out test titles faster than the human eye can process. This gives you warm fuzzies knowing that things are actually happening, but it's not super useful. Which test failed is generally the most valuable feedback your test suite gives you, so it seems silly to make users wait until all the tests have run to deliver valuable information we already have.

My first idea was that, in addition to the current test, the reporter should persist the title of the most recent failure. This would work well if there was a single failure early on, but not so good if there were lots of failures, rapid fire, throughout the test run.

*UPDATE: * We are going with @vdemedes solution here: #653 (comment)

I now think we could do this even better by processing keys from stdin, I am thinking something like the following:

• The tests titles fly by, you see the error count incrementing, and the title of the most recent failure is "sticky" (shown until a new failure comes along). This is basically the same idea I had before.
• Pressing ⬆️ puts you into error review mode, and the title of the most recent failure (at the time the ⬆️ was pressed) is now really sticky - incoming failures do not cause the "sticky" failure title to be updated.
• Pressing ⬆️ again takes you one failure earlier in the "failed test" list.
• Pressing ⬇️ takes you later in the list.
• Pressing enter/return exits error review mode.

---

IssueHunt Summary

m5x5 has been rewarded.

Backers (Total: $60.00)

• issuehunt ($60.00)

Submitted pull Requests

• #2488 Consolidate mini and verbose reporter

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[novemberborn]

This would only be useful for test suites that take a really long time to execute though, right?

[vadimdemedes]

I appreciate your time & effort that went into thinking this approach through, but I must say I'm a bit skeptical about having to navigate the test results. Interactive test results would complicate the UX, imo.

[jamestalmage]

This would only be useful for test suites that take a really long time to execute though, right?

Yep.

Interactive test results would complicate the UX, imo

If the user doesn't take action (by hitting ⬆️) the experience doesn't change.

---

I just want to get the important information (test failures) to the user as quickly as possible. Happy to entertain alternative ways to do that.

[vadimdemedes]

I've got an idea, will post a demo soon.

[vadimdemedes]

If an error is encountered, it gets displayed immediately and live test counter moves down. That way user does not need to wait for tests to complete to see the errors & their stacks.

[sindresorhus]

@vdemedes I like this!

[novemberborn]

@vdemedes yea, output errors as they occur but otherwise remain "mini".

[jamestalmage]

👍

[novemberborn]

@vdemedes I can't recall whether you made the change you suggested above. Perhaps you could open an issue for it?

---

Do we want to keep this ticket open at all? It's pretty far out there 😜

[jamestalmage]

Let's leave this open - my first idea wasn't great - but @vdemedes plan is. I'll update the description to say we've agreed on @vdemedes plan.

[vadimdemedes]

@novemberborn totally forgot about this one, will submit my fix as a PR soon.

[IssueHuntBot]

@IssueHunt has funded $60.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[issuehunt-oss]

@sindresorhus has rewarded $54.00 to @m5x5. See it on IssueHunt

• 💰 Total deposit: $60.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $6.00