[Feature]: Improved console.* usability when focusing a test

[eps1lon]

🚀 Feature Proposal

Make console.* more useful when focusing on a single test by either:

1. Allowing to not print the test names of skipped tests (and related information such as obsolete snapshots)
2. Moving console.* calls below the test summary

Motivation

Especially in large test suites I usually focus on a single test when working on a bug/feature. In some cases (e.g. new codebase, simple debugging instructions) I prefer to use console.* methods.

However, Jest currently displays them before the test summary which means I have to constantly scroll back up or, even worse, in the case of test failures I have to scroll between bottom (for the failure) and top (for the log).

Example

In the React codebase (51947a14bb24bd151f76f6fc0acdbbc404de13f7) with

diff --git a/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js b/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
index 435e90d9b1..cce594175c 100644
--- a/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
+++ b/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
@@ -126,6 +126,8 @@ describe('ReactDOMServerSelectiveHydration', () => {
   });

   it('hydrates the target boundary synchronously during a click', async () => {
+    console.log(1)
+    throw new Error()
     function Child({text}) {
       Scheduler.unstable_yieldValue(text);
       return (

$ yarn test ReactDOMServerSelectiveHydration --watch --testNamePattern 'hydrates the target boundary synchronously during a click'
console.log
    1

      at Object.<anonymous> (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:129:13)

 FAIL  packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
  ReactDOMServerSelectiveHydration
    ✕ hydrates the target boundary synchronously during a click (99 ms)
    ✓ hydrates the target boundary synchronously during a click (createEventHandle) (50 ms)
    ○ skipped hydrates at higher pri if sync did not work first time
    ○ skipped hydrates at higher pri for secondary discrete events
    ○ skipped hydrates at higher pri if sync did not work first time (createEventHandle)
    ○ skipped hydrates at higher pri for secondary discrete events (createEventHandle)
    ○ skipped hydrates the hovered targets as higher priority for continuous events
    ○ skipped replays capture phase for continuous events and respects stopPropagation
    ○ skipped replays event with null target when tree is dismounted
    ○ skipped hydrates the last target path first for continuous events
    ○ skipped hydrates the last explicitly hydrated target at higher priority
    ○ skipped hydrates before an update even if hydration moves away from it
    ○ skipped fires capture event handlers and native events if content is hydratable during discrete event
    ○ skipped does not propagate discrete event if it cannot be synchronously hydrated
    can handle replaying events as part of multiple instances of React
      ○ skipped Inner hydrates first then Outer
      ○ skipped Outer hydrates first then Inner

  ● ReactDOMServerSelectiveHydration › hydrates the target boundary synchronously during a click

      128 |   it('hydrates the target boundary synchronously during a click', async () => {
      129 |     console.log(1)
    > 130 |     throw new Error()
          |           ^
      131 |     function Child({text}) {
      132 |       Scheduler.unstable_yieldValue(text);
      133 |       return (

      at Object.<anonymous> (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:130:11)
      at asyncGeneratorStep (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:310)
      at _next (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:648)
      at packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:813
      at Object.<anonymous> (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:554)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 14 skipped, 1 passed, 16 total
Snapshots:   0 total
Time:        0.844 s

Notice the, in my opinion, wasted space by the list of skipped tests.

Related issues: https://github.com/facebook/jest/issues/2169

Pitch

The current behavior encourages small test files or straight up not focusing on a single test. However, iteration speed for debugging is very important so people may be hesitant to add more tests due to Jest becoming harder to read when focusing on a single test.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[eps1lon]

Comment

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[eps1lon]

Comment

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[eps1lon]

bump

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[eps1lon]

bump

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[eps1lon]

Comment

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[eps1lon]

42

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[JESii]

Still an issue that needs attention -- the displayed order of console.log messages is a real pain when working with Jest output. Why no response from the maintainers?

[SimenB]

This sounds like it can just be a custom reporter. Or possibly configuration for the built in reporters?