Feature request: report failing tests at the bottom of the spec reporter

[MoLow]

What is the problem this feature will solve?

when test runs fail, it is currently needed to scroll up and manually search for the failing tests,

What is the feature you are proposing to solve the problem?

this behavior exists in some popular test runners (mocha, jest, playwright, etc),
re-printing the list of failing tests after the summary can be very useful

What alternatives have you considered?

scrolling to find the failing tests manually

[itsAfnanAlam]

Hi, can I take this?

[HinataKah0]

Hi,

I am interested to work on the changes.

Based on my understanding:

• We need to output the failing tests report in root Test (lib/internal/test_runner/test.js).
• Since #handleReportItem (lib/internal/test_runner/runner.js) immediately emits the test output to stream, we need to store the error output somewhere.
• Eventually, all children Tests need to propagate the error outputs to their parents.
• ArrayPrototypePush is concurrency safe.

Please correct me if I am wrong.
Draft commit here

I need suggestions about the output format.
I feel that if we output the whole diagnostics (including stack trace) again, it will make the output too cluttered since too many duplicates. Maybe we can omit the stack trace before the summary?
And I am worried about the memory usage, should we allow this feature to be disabled by choice (using flag)?

Also may I know how to properly re-generate test_runner_default_reporter.out?
Thanks!

[MoLow]

@HinataKah0 I would expect the change to only affect the spec reporter
whenever it receives a test:fail event, it can store the failed test, and when completed the reporting, it can print the failutes in the same format, at the end of the stream and with no indentation

[HinataKah0]

Hi @MoLow ,

Thanks for the kind reply! Now the implementation is quite clear for me.
However, I noticed that we need to introduce a new event to mark the end of tests (e.g. test:eot).
Because test:diagnostic is sent a few times so it doesn't signify the ending. Actually I can maintain a counter but I don't think it's clean.

To illustrate what I am talking about here

Does this match to what you have in mind?

I think adding file path will be very useful.

It took me a while to understand how nodejs' build testing works (and to understand why I broke some tests). 🤣

Thanks!