Consider print the captures before the report

[merlinran]

When there's just one failed test, which is the most common scenario, the full output looks like this.

.............................................F.
====================== FAILURES =================
__________________________ XXX test ____________________

The report

----------------- Captured xxx call -------------
...
----------------- Captured xxx teardown -------------
...
============ short test summary info ==========
FAILED code/path - XXX error
1 failed, 3 deselected, 11 warnings in 5.29s

The captures can be very long, because the developer wants to have every details to help them figure out the problem. Since the short summary doesn't show the line number and the code around it, the developer would need to scroll back or search for the error message to see them. If the report doesn't reveal the problem immediately, they would check the logs around the time the error was happening, which, if they have --exitfirst enabled, are near the end of the output, so they would scroll down again. This back and forth can reduce productivity.

My suggestion is to reorder the output so the developer can always see the key information right away at the bottom of the screen, then scroll back or search for things to dig deeper.

.............................................F.
====================== FAILURES =================
----------------- Captured xxx call -------------
...
----------------- Captured xxx teardown -------------
...
__________________________ XXX test ____________________

The report

============ short test summary info ==========
FAILED code/path - XXX error
1 failed, 3 deselected, 11 warnings in 5.29s

[merlinran]

This doesn't solve all problems #8843 tries to solve, but can mitigate a bit.