@thymikee Any idea why this is happening?

No idea, but I'd try to minimize the example, e.g. by removing typescript

I'm able to repro without Typescript

Can confirm Node 7.4 eats console logs, but it works on Node 7.5.0, 7.10.0, 8.0.0 and 8.1.2.
Please upgrade your Node version. Closing

@thymikee What about Node 6, which is the current LTS release? (Looks like I'm hitting this too, though haven't debugged it enough yet. However, I'm limited to LTS releases for now, so can't upgrade).

Tested on v6.11.0, still shows console.logs.

Ah, I might be hitting some other problem. Thanks, @thymikee, I'll go back to debugging it a bit more.

I was running Node 7.3.0 unknowingly (wrong version via n) and it wasn't logging. Switched to 8.1.1 and it logged again.

@thymikee - I don't see how that is the solution? ...I am not able to upgrade my node version

I guess I'm a little confused how this would be considered a Node bug and not at least have something to do with Jest itself. Using Node v7.4.0, with Jest v19.0.2 I see console logging from my tests. Simply updating Jest to v20.0.4 (without making any changes to any other configuration) causes console logging to no longer appear. Is there something that I'm missing?

@thymikee So, I've upgraded my node version and I see no console logs on Node 8.2.1 Winx64 + Jest 20.0.4. I have to use a fallback for now

  console.log = s => {
    process.stdout.write(s + "\n");
  };

and I'm pretty sure it should be fixed in Jest, since previous versions didn't have this issue.

@nowherenone can you test if it happens on latest alpha release jest@test?

@thymikee Just tried with jest@test on node 8.2.1 but same result. console.log statements are always swallowed.

@thymikee The problem is in the BufferedConsole module, where the Console constructor parameters don't match with the expected ones.

I've opened a PR, maybe it would help: https://github.com/facebook/jest/pull/4157

I think the problem here is that Jest buffers messages but there is something that causes to bail out (or an infinite loop etc.). You'll need to use --verbose to print the messages directly to the output stream.

This is ridiculous - I am triggered by the amount of useless responses from @cpojer (in every issue and PR I go to) and trying to put everything on everyone else like somehow we aren't smart enough.

Don't use Jest - that's my answer if you're wondering. Find a new testing framework.

describe('index', () => {
  it('doesnt print anything', () => {
    console.log('Hellllooo');
    expect(true).toBe(true);
  });
});

$ yarn test -- src/__tests__/index.spec.js --verbose
yarn test v0.27.5
warning package.json: No license field
$ jest "src/__tests__/index.spec.js" "--verbose"
 PASS  src/__tests__/index.spec.js
  Index
    ✓ doesnt print anything (2ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.969s, estimated 2s

$ jest "--version"
v20.0.4
$ node --version
v7.4.0

I am sure I'll just be told to install a newer version of Node Lmao - what a joke 😂 😂 😂

@nf071590 cannot repro, works on repl.it with exactly the same Jest and Node versions: https://repl.it/KYLc/0

Please come up with a serious repro before ranting about project maintainers.
Cheers!

Not sure what to do about this. I literally pasted your example into a file, and ran Jest, and it works as advertised on my Mac, with the latest master version of Jest as of a minute ago. See:

Throwing in since I'm on windows (node 8.4, jest 21.0.0-alpha.2), console.logs are _sometimes_ hidden if you don't use --verbose, but seem to show consistently with it. Happy to update with results using node 7 and stable jest when I get a minute.

The same problem here.

describe('index', () => {
  it('doesnt print anything', () => {
    console.log('Hellllooo');
    expect(true).toBe(true);
  });
});

$ node --version
v7.4.0
$ jest "--version"
v21.1.0

Currently encountering same issue on node v8.7.0 (npm v5.4.2).

This is still an issue

Can you provide a reproduction?

FWIW, I ended up here because I was having the exact same issue. Node v7.4.0. Upgraded my Node version, and console.log prints as expected now, even without --verbose. V7.4.0 may not be the only version to have this issue, but it does seem to be version-related, and a non-issue for some Node versions. I'm now on Node v8.3.0, which seems to work.

That said, prior to upgrade I had the same versions as @nf071590 , and the same problems. I'm not sure why it doesn't happen on repl.it, but it's not some weird thing only happening on his computer.

I can reproduce this with node 8.9.0 and jest 21.2.1, macOS 10.12.6 (16G1036)

@SimenB I could but it looks like this issue has been discussed to death here and elsewhere. The multi-(child)process nature of jest means that it will overwrite console.logs, and without a massive rewrite that is not going to change. Anyone who comes to this thread and wants to avoid the issue where using the --verbose flag disallows debugging with console.log, should use the --watch flag. This will avoid the child worker processes from overwriting and allow you see verbose output with console logs. --watch is very fast and adds more value by focusing attention on the tests and code that have changed, by only running those tests that are changed on save.

In my case I found the verbose messaging would eat some but not all console.log messages. I removed the verbose option and it seems to somewhat work!

I just upgraded my node version from v6 to v9 and one of my test files is consoling.

I've been battling with the issue for weeks. I'm glad it works now

The problem still persists with --verbose when combined with --forceExit - I think the reason for that is that console.log outputs to stdout while jest writes to stderr and when --forceExit there may still be content in stdout not be flushed

I found the following solution (without the need for --verbose) to fix both console.log not showing and/or console.log being buffered and not displayed live

command
jest .... --forceExit --setupTestFrameworkScriptFile ./src/tests/jestShim.js

contents of jestShim.js

const { Console } = require('console');
global.console = new Console(process.stderr, process.stderr);

Same issue-never see console.log output ever.

Node 9.80 Jest 22.4.2 Mac OS 10.13.3

Not one of the workarounds suggested here worked for me.

As always, please create a reproduction we can pull down to test. I haven't encountered this issue, so I'm not sure how to begin fixing it

Workaround of @ledbit worked for me
NPM 5.3.0
jest 22.4.3

• Mac OS

I'm still at the point of needing a reproduction.

--forceExit seems somewhat broken, but I've not encountered it when not using that flag

[Using react-scripts forked to use latest Jest v23.0.0, node v8.11.2]

I finally got the logs to show up by tagging each one with a particular string of characters (e.g. @@@) and running:

yarn test --verbose | grep '@@@'

It's a terrible hack (you lose all console coloring, but you do still see test failures and a final test summary) but it's the only thing that's worked so far. I tried everything else in the comments above. Note that the --verbose arg is necessary for this solution (and it's being implicitly combined with --watch via react-scripts).

This is still an issue. I'm using jest v22.4.3 on Node 10.1.0 and I only see the first console.log statement of my app, all of the rest are ignored. When I set my logging library to stream to stdout I can see some of the logs but they don't appear in the right order.

Jest's job as a test runner is to help us debug and fix our code. That can simply not be achieved without logs.

@thymikee please re-open this issue

@thanpolas feel free to create a new issue with a repository showing the bug so we can investigate :). Also, please use Jest 23, as that's the latest.

I figured out my problem, the logging was happening through a logger that was streaming to stdout, when redirected to console.log I forgot to invoke the stream writer callback so the stream stopped sending logs.

For what it's worth, I've seen differences between Terminal and iTerm2.

I think an option to instruct jest to not do magic on stdout and console would be very beneficial for everyone

Here is one instance of the bug that I managed to reproduce. Not sure if there are multiple sources though:

https://github.com/spion/jest-logging-repro

yarn install; yarn repro

Setup: Jest is in watch mode, with verbose flag turned on, with at least two test files running.

Theory: Output from one of the workers moves the console cursor to the wrong place overwriting wrong content.

Observation in console:

 RUNS  tests2/other-tests.js
 RUNS  lib/example.spec.js
 PASS  tests2/other-tests.js
  bar
    ✓ always is true (17ms)

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.673s
Ran all test suites.

Watch Usage: Press w to show more.

If I remove the console log, visually "RUNS" get overwritten as intended:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)

 PASS  tests2/other-tests.js
  bar
    ✓ always is true (5ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.597s
Ran all test suites.

Watch Usage: Press w to show more.

If I add 3 console logs:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)


 RUNS  tests2/other-tests.js

Test Suites: 1 passed, 1 of 2 total
Tests:       1 passed, 1 total
Snapshots:   0 total
  console.log tests2/other-tests.js:5
    JEST

 PASS  tests2/other-tests.jsests.js:6
  bar
    ✓ always is true (19ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 totalTime:        1.788sRan all test suites.

Watch Usage: Press w to show more.

Node version:

30656 % node --version
v8.11.2

I think @spion is honing in on it. Nice easy repro.

Can confirm that this happens on Node v8.11.1 LTS and only happens on watch and watchAll mode. without watch modes, it's fine.

I have the same issue with Node v10.6.0 and Jest 23.4.1

Yeah, me too. Just found that -w 1 gets the logging working again, which fits with @spion's hypothesis.

node 8.11.3
jest 23.4.0

I'm finding this issue, or at least a similar issue, when I turn on file regex matching (pressing p in watch mode). With all turned on, the logs are printed as expected. Note --verbose is not on here.

Sample 1

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.error('r2');
    console.error('r3');
    ...

With all watching (prints both logs and errors:

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.error src/components/__tests__/FormValidator.js:57
      r2
    console.error src/components/__tests__/FormValidator.js:58
      r3

In file regex mode (only prints the first log and not the errors):

Test Suites: 0 of 1 total
Tests:       0 total
Snapshots:   0 total
  console.log src/components/__tests__/FormValidator.js:56
    r1

 PASS  src/components/__tests__/FormValidator.jsidator.js:57
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (32ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Sample 2

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.error('r3');
    ...

all (prints both log and error as expected):

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.error src/components/__tests__/FormValidator.js:59
      r3

watch (nothing is printed with the above code):

Snapshots:   0 total
 PASS  src/components/__tests__/FormValidator.jsator.js:56
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (20ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Test Suites: 1 passed, 1 total

Sample 3

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.log('r2');
    console.log('r3');
    console.log('r4');
    ...

all (prints all four logs expected):

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.log src/components/__tests__/FormValidator.js:57
      r2
    console.log src/components/__tests__/FormValidator.js:58
      r3
    console.log src/components/__tests__/FormValidator.js:59
      r4

watch (only the first two logs are printed with the above code):

Snapshots:   0 total
  console.log src/components/__tests__/FormValidator.js:56
    r1

  console.log src/components/__tests__/FormValidator.js:57
    r2

 PASS  src/components/__tests__/FormValidator.jsator.js:58
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (31ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Test Suites: 1 passed, 1 total

I am not sure what I did but I think the order of how you set up jest matters. I think some configurations may overwrite each other. I'm getting both the test and the log output.

node -v v8.11.2
jest -v 23.4.0

Below is my jest configuration in my package.json

```
"jest": {
"transformIgnorePatterns": [
"/node_modules/"
],
"setupFiles": [
"/src/setupTests.js"
],
"testEnvironment": "jsdom",
"verbose": true,
"projects": [
{
"displayName": "COMPONENTS",
"setupFiles": [
"/src/setupTests.js"
],
"modulePaths": ["/src/"],
"testMatch": ["/src/components/__tests__//.test.js"]
},
{
"displayName": "REDUCERS",
"setupFiles": [
"/src/setupTests.js"
],
"modulePaths": ["/src/"],
"testMatch": ["/src/reducers/__tests__//.test.js"]
},
{
"displayName": "ACTIONS",
"setupFiles": [
"/src/setupTests.js"
],
"modulePaths": ["/src/"],
"testMatch": ["/src/actions/__tests__/*/.test.js"]
}
]
},

Here are my dependencies

"dependencies": {
"babel-core": "^6.26.3",
"babel-jest": "^23.4.0",
"babel-loader": "^7.1.5",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"dotenv": "^6.0.0",
"express": "^4.16.3",
"jest": "^23.4.0",
"react": "^16.4.1",
"react-dom": "^16.4.1",
"react-redux": "^5.0.7",
"react-scripts": "1.1.4",
"redux": "^4.0.0",
"regenerator-runtime": "^0.12.0"
},

output from just running jest

PASS REDUCERS src/reducers/__tests__/comments/index.test.js
✓ handles actions of the type SAVE_COMMENT (4ms)
✓ handles action with unknown type

PASS ACTIONS src/actions/__tests__/index.test.js
saveComment
✓ has the correct type (1ms)
✓ has the correct payload (1ms)

PASS COMPONENTS src/components/__tests__/App/index.test.js
✓ Should show a CommentList (5ms)
✓ Should show a CommentBox (1ms)

PASS COMPONENTS src/components/__tests__/CommentBox/index.test.js
✓ has a text area (23ms)
✓ has a button (3ms)
the text area
✓ has a text area that users can type in (9ms)
✓ when form gets submitted, text area gets emptied (5ms)

PASS COMPONENTS src/components/__tests__/CommentList/index.test.js
✓ creates one LI per comment (32ms)

Test Suites: 5 passed, 5 total
Tests: 11 passed, 11 total
Snapshots: 0 total
Time: 3.79s
Ran all test suites in 3 projects.
console.log src/components/__tests__/CommentList/index.test.js:26
0

console.log src/components/__tests__/CommentList/index.test.js:27
Test

```

This issue should be reopened, console output swallowed by jest too, my environment is:

→ node --version
v8.11.3

→ npx jest --version
23.4.1

I tried with a clean setup and everything works fine.

// console.test.js
describe('jest should console output', () => {
  test('should console.log output be print', () => {
    console.log('console.log')
    expect(1).toBe(1)
  })

  test('should console.error output be print', () => {
    console.error('console.error')
    expect(1).toBe(1)
  })

  test('should console.info output be print', () => {
    console.info('console.info')
    expect(1).toBe(1)
  })
})

output:

So I thought the problem might be related to my jest configuration:

{
  "globals": {
    "API_SERVER_PLACEHOLDER": "SOME_API_ADDRESS"
  },
  "moduleFileExtensions": [
    "js",
    "jsx"
  ],
  "transform": {
    "^.+\\.jsx?$": "babel-jest"
  },
  "moduleNameMapper": {
    "\\.(css|less|sass|scss|png)$": "<rootDir>/__mocks__/styleMock.js",
    "\\.(gif|ttf|eot|svg|png)$": "<rootDir>/__mocks__/fileMock.js"
  }
}

My instinct told me to check verbose and after remove it everything is fine.

recap

jest version 23.4.1 with configuration verbose set to true would cause console output to be swallowed.

propose to change the default output stream to stdout: https://github.com/noscripter/jest/pull/1

It's broken again?! Why does this keep breaking?

I've worked around this with:

expect(str).toBe("not this");

😬

If you have verbose: true in your package.json, or you're running jest with the flag --verbose (or both?), try removing them. When I don't use those flags I get consistent display of log messages.

Nevermind that doesn't help anymore.

I can often see the log output for a split second _before_ the full test summary prints to the console. I'm having to console.log about 4-5 times in a row to get the output showing, and even then the last log will be chopped off halfway (for example when printing a large object, only the first half will be visible in the last printed log).

It's also very hard to predict. Sometimes one or two console.logs will suffice, whereas other times I have to put three to five in a row. It also doesn't matter if my logs are in the code I'm testing, or in the test cases themselves.

Seems like jest is printing the logs, then clearing the output before printing the full test summary, when really it should be retaining those logs.

I've accepted at this point that I have to copy-paste the logs multiple times to see them in the console.

console.log does work if you run a specific test file only

yarn test <your-test-file-name>

e.g.
yarn test FormValidator

FYI I run my repro with the following command:

script -qfc 'yarn repro' /dev/null > raw.log

Thats zsh - you might want script -qfce in bash

and then I viewed the log with cat -vet raw.log. Here are the results:

^[[2K^[[1G^[[1myarn run v1.7.0^[[22m^M$
^[[2K^[[1G^[[2m$ jest --watch^[[22m^M$
^[[2J^[[3J^[[H^[[1m^[[2mDetermining test suites to run...^[[1m^[[22m^[[999D^[[K^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[0m^[[7m^[[1m^[[32m PASS ^[[39m^[[22m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A  foo^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A    ^[[32mM-bM-^\M-^S^[[39m ^[[2madds 5 (4ms)^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^[[999D^[[K  ^[[2mconsole.log^[[22m ^[[2mtests2/other-tests.js:5^[[22m^M$
    JEST^M$
^M$
^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[0m^[[7m^[[1m^[[32m PASS ^[[39m^[[22m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A  bar^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A    ^[[32mM-bM-^\M-^S^[[39m ^[[2malways is true (15ms)^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[999D^[[K^[[1mTest Suites: ^[[22m^[[1m^[[32m2 passed^[[39m^[[22m, 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m2 passed^[[39m^[[22m, 2 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1.128s^M$
^[[2mRan all test suites^[[22m^[[2m related to changed files^[[22m^[[2m.^[[22m^M$
^M$
^[[1mWatch Usage^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22ma^[[2m to run all tests.^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22mf^[[2m to run only failed tests.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m p ^[[2mto filter by a filename regex pattern.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m t ^[[2mto filter by a test name regex pattern.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m q ^[[2mto quit watch mode.^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22mEnter^[[2m to trigger a test run.^[[22m^M$

Hope this helps. Looks like there is a miscount of control codes at a certain point.

The end result looks like this:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (4ms)


 RUNS  tests2/other-tests.js

 PASS  tests2/other-tests.js2 total
  bar
    ✓ always is true (15ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.128s
Ran all test suites related to changed files.

Watch Usage
 › Press a to run all tests.
 › Press f to run only failed tests.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.

The console line is missing, and pass is written two lines too far down, likely due to intertwining with the console.log not being taken into account when going up to display the "PASS"

edit: Added this summary in a gist for easy search and manipulation: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

p.s. To reproduce this with current master it might need some coercing. When you enter watch mode, press and hold "a" for a while - the console.logs will start to go out of control at some point (appear at unexpected places and times)

Also I forgot - I am on ubuntu bionic, if that makes any difference WRT terminal behavior:

% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:    18.04
Codename:   bionic

Me too. @spion has nailed what I'm seeing. I only discovered it because I have tests on slow, async code. I see console output, then it is overwritten by the test results summary.

For what it's worth, I've reverted to [email protected] and doing so resolves the problems I was having with test summary output being written over console output in [email protected].

Update - I believe I've found a minimal patch that makes some progress, but it took me a while to understand the interaction between Jest reporters and the Status generator

Jest monkey-patches the process stderr and stdout streams' write methods with its own writer. That writer writes down the output of jest-cli Status.js, which contains things such as the number of tests in progress, a progress bar, the elapsed time and so on.

Whenever there is a write instruction on that stream, that instruction is replaced with a "delete" instruction for the status (going up using ANSI control codes), the original write, and a "write the status again" instruction. Thus the illusion that the status is always at the bottom of the screen, whereas the text scrolls above it.

(Of course, its a bit smarter than that - the writes are buffered and the buffered data is only really written once every 100ms together with the status)

However, the parallel test runner (used in watch mode, which sets runInBand to false) runs other workers. Those workers are set up to "inherit" the stdio stream of the original process. Unfortunately, that doesn't mean they inherit the patched version that updates the status! If those writes happen, they will be

1. added after the status (the status does not get erased)
2. will be erased on the next status erase (making the previous status partially visible too, since the erase doesn't move up sufficiently to erase both the console output and the old status update)

To make sure the patched version receives those tty writes, its necessary to switch the child processes streams from "inherit" mode to "pipe" mode. This way the process outputs are available as streams in the child process instead of directly going to the main stdout/stderr. We also need to manually pipe the streams:

diff --git a/packages/jest-runner/src/index.js b/packages/jest-runner/src/index.js
index 2f4dd724..618a8cbf 100644
--- a/packages/jest-runner/src/index.js
+++ b/packages/jest-runner/src/index.js
@@ -97,11 +97,14 @@ class TestRunner {
     // $FlowFixMe: class object is augmented with worker when instantiating.
     const worker: WorkerInterface = new Worker(TEST_WORKER_PATH, {
       exposedMethods: ['worker'],
-      forkOptions: {stdio: 'inherit'},
+      forkOptions: {stdio: 'pipe'},
       maxRetries: 3,
       numWorkers: this._globalConfig.maxWorkers,
     });

+    worker.getStdout().pipe(process.stdout);
+    worker.getStderr().pipe(process.stderr);
+
     const mutex = throat(this._globalConfig.maxWorkers);

     // Send test suites to workers continuously instead of all at once to track

Manually piping the streams ensures that the monkey-patched write does get called by node.

This breaks a lot of integration tests, however they're mainly broken due to missing color. Doing

diff --git a/packages/jest-worker/src/worker.js b/packages/jest-worker/src/worker.js
index 5eee64af..5e5126eb 100644
--- a/packages/jest-worker/src/worker.js
+++ b/packages/jest-worker/src/worker.js
@@ -94,6 +94,8 @@ export default class {
         {
           cwd: process.cwd(),
           env: Object.assign({}, process.env, {
+            // $FlowFixMe: Does not know about isTTY
+            FORCE_COLOR: process.stdout.isTTY,
             JEST_WORKER_ID: this._options.workerId,
           }),
           // Suppress --debug / --inspect flags while preserving others (like --harmony).

brings down that number significantly but its still pretty high:

Test Suites: 51 failed, 232 passed, 283 total
Tests:       149 failed, 7 skipped, 2706 passed, 2862 total
Snapshots:   19 failed, 17 obsolete, 996 passed, 1015 total

I don't think there is a way around this - the output is drastically changed, as a lot more writes end up adding the status update now.

edit: there is also the issue of node flushing the output stream too late in certain situations, long after the child process sent a success message to the parent.

please fix, this really hurts productivity with jest

Downgrading to [email protected] brings back console log output. Had to set --env node to make it work though. Please fix this.

Currently it seems the only way I can get console logging to be reliable is to log the same thing 3-4 times in a row. Jest will only block a certain number of them. Still very annoying.

Is there any update on this? I am running jest 23.4.1 and node 9.11.1 and am sometimes getting console log output and sometimes not.

Two years of no console logs made me a better developer. Thanks team Jest!

I can't believe this is still an issue. Why is the issue closed?

I mean, who would ever want to debug their failing tests, right?

Like @jonogilmour mentioned if I log something once it doesn't get displayed but logging things twice I will get one of them to display.

FWIW, the --verbose=false workaround works for me. In my package.json:

"scripts": {
...
    "test": "react-scripts test --env=jsdom --verbose=false",

Some other observations:

• Removing --env=jsdom (not an option for my real application) made it work without --verbose=false.
• Running the test directly with jest (not through react-scripts) also made it work.
• When an assertion fails and you get much more output from jest, much more of your console logs gets overwritten also.

Hello guys/girls,
I also met the famous jest console log problem when running testing in --watch mode.
The solution was to use --watchAll instead of --watch. The summary of tests became uglier, but the logs showed as expected.

macOS High Sierra
node v8.11.3
jest: 23.6.0
ts-jest: 23.10.4

For me this in beforeAll

  console.log = s => {
    process.stdout.write(s + "\n");
  };

and this in the shell did the work:

yarn test > test.log

For me, switching to mocha solved the problem. It is very trivial to switch, since the DSL is very similar. You can even keep using JEST' expect-library: https://www.npmjs.com/package/expect

It's almost as easy as removing jest and installing mocha.

Edit: Spam or not, it is the easiest solution out here.

This issue is really hurting, I wish the maintainers could fix this as soon as possible, because Jest is meant to increase productivity, not the other way round right?

Anyway, the following is what I'm using write now:

export const log = (s: any) => {
    console.log(s);
    console.log(s);
    console.log(s);
    process.stdout.write(s + "\n");
};

You gotta spam your way out.

Confirmed that --verbose=false fixes the issue.

--verbose=false does not work for me with version 23.6.0

OMG this is a pain :/ november 2018

Please reopen this issue

try to set silent: false in jest.config.js... in my case it helped me

None of the solutions work.
NodeJS: v8.12.0
Jest: v23.4.1

I've been using Jest for months and it's great and while this bug is _super annoying_ , the workaround I've always used is to make a junk assertion since that will log to console every time.

Example, when trying to log out a mock call:

expect('hello').toEqual(childFunc.mock.calls[0]) prints out:

It's not ideal but it gets the job done and allows me to finish writing my tests.

Running Jest with a --watch flag.
Jest version 23.5.0
Node version 8.11.3

This is a decent example of "too much magic" going on underneath the hood, and the consequences of that when something goes wrong. I'm not convinced grouping console.log output is worth a year and a half of missing console.log statements. 😕

Agree with the above -- this is not quite a showstopper, but it makes Jest painful in way that's completely unnecessary.

My "workaround" is that much of the logic uses log4js, so for where I bend Jest to server-side code I'm good. Sadly I have a large amount of client side code where I usually copy and paste four copies of each console.log since eventually one of them seems to show up.

Using expect to log info is an okay workaround if you're logging from within a test (especially since you can create a snippet for it with a keyword like logjest in your editor), but that falls short whenever you need to dig deeper and log from within the actual functions your tests are calling.

How about CI=true yarn run test?

Sorry for what I said before, but it works well without the title of the test cases, I mean, without the "--verbose" option, I think that --verbose does some kind of formatting and replaces the stdout stream.
So, for me I have been like 2 months and everything is working well.
And if anybody wants to use that option then only append it to your npm commands like so: npm run test:integration -- --watchAll --verbose --coverage --etc

Can people with the issue test [email protected]? It includes #6871

@jamesta696 Hi, I think that you need to post that kind of questions on StackOverflow using the tag of "jest" here because the discussions here are for "issues", nevertheless, I know that somebody could help you, but the issue here could be closed because the main issue is not being discussed.
And for now, I cannot give you an answer for that question because I'm not developing something for react and the frontend, also, I'm not a member of jest, but let's try to follow the rules.

@SimenB I've updated jest (to your mentioned version) & tried placing a few console.log statements in my project that had the issue. So far, it seems to be fixed: All console.logs appear. I'll continue to use it and let you know if I encounter the issue again.

FYI: I was (and still am) using jest --watchAll

@tobyhinloopen Cool to see a proof of the progress that mentioned @SimenB .

that's awesome @tobyhinloopen!

I also can confirm that [email protected] works fine and you can see all of the console logs without --verbose=false.

I also can confirm that [email protected] works fine and you can see all of the console logs without --verbose=false.

+1. can also confirm. glad to see this is working. nice work, Jest folks! 😄

I can confirm as well! It's like Christmas. 🎅

😃

just need no wait till create-react-app updates

I am running jest version 24.0.0, yet I still can't see console.log or console.error. Wondering what I might be doing wrong.

Make sure they're not mocked

This is really weird. There seems to be an issue with async handling. I can't get the errors to be displayed. Even if wrapped to try/catch blocks, I can't see the error.

The parameter generator is correct for sure, If I remove the async function call, then it logs correctly. It also returns the correct string when it's outside the for loop.

Jest version is 24.0.0, node is 10.5

@tiborsaas Your test will probably have finished before the console.log runs.
If you want to wait for the iteration over changedGenerators, you'll need something like

await Promise.all(changedGenerators.map(async (generator) => {/* ... */}))

Thanks for the reply, but it's not really the case, some error prevents the console.log to be displayed. There is another async function which works fine with console.log if I call it in the forEach callback.

Edit: actually by line-by-line debugging I know the problem is with

const archives = await fs.readdir(archiveDir);

However this jest issue is about logging things. I don't want to derail the conversation.

You may still be experiencing a bug, just wanted to point out (without knowing your exact code) that it's generally a bad idea in general to fork a bunch of promises like this without awaiting them, because they might reject after your test has finished :)

I agree, but I want to run the expect calls in the forEach because I don't know upfront how many changes I have to deal with.

Unfortunately the Promise.all approach didn't fix anything.

Did you use map instead of forEach? The point is to return an array of promises to Promise.all

@SimenB yes, I know.

If there is an error, I can't see it.

@tiborsaas You're not waiting for Promise.all to complete: use await Promise.all(...)

Did that too, same result. :(

what if you add await new Promise((resolve) => setTimeout(resolve, 1000)) below your promise.all?

Can you open up a new issue with a reproduction? I believe the issue reported by the OP is fixed while you're seeing a different one (no matter if you handle async right or not, you should still see the log statement)

Yeah it's strange indeed, something like

test('stuff', () => {
    setTimeout(() => console.log('hi', 500));
})

is usually still printed in some way

He's using a callback function as 2nd argument of Promise.all([...], callback). He should use Promise.all([...]).then(callback). Maybe that solves his problem, I think the 2nd argument of .all is ignored and never executed (so your logs will never be executed). @tiborsaas

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

Yeah that's wrong, but log statements should still show up

@SimenB Nope, 2nd argument is ignored.

> Promise.all([Promise.resolve(true)], () => console.log("hi")).then(console.log, console.error);
Promise {
  <pending>,
  domain: 
   Domain {
     domain: null,
     _events: { error: [Function: debugDomainError] },
     _eventsCount: 1,
     _maxListeners: undefined,
     members: [] } }
// output:
// [ true ]

Yeah, got confused with it, sorry. Thx @tobyhinloopen

const lol = await Promise.all(versions); worked as expected.

In that case, the log statements might be lost since the function is never called, but you should still see log statements in the original forEach case since node will wait for the promises to complete before exiting the process. So it's still a bug, even though it's a user error

PR: #7731

I use https://www.npmjs.com/package/debug to do logging. Would that work with Jest?

No, not until we do #6524.

I'd recommend mocking debug in your tests and using console.log if you wanna se them

For reference, console messages can get lost if they are printed after the tests have completed, see the comments at the bottom of #7731. This might be the reason for some, but probably not all of the missing console messages reported here.

The --verbose worked for me. Before using --verbose, some, but not all messages were lost. I am using node v10.15.3 and jest v21.2.1

Still a problem for me, console logs don't show in Jest

despite the latest announcement in the blog that the problem has been finally solved, the problem still exists, my console logs sometimes do not show up again, I'm using jest v24.8.0.

And my works just fine 🤷‍♂️. Please post a reproduction we can investigate. We're not wizards, we can't see your code that's failing to log output.

actually, after investigation, logs related to API testing(like supertest) doesn't work. expected :/

@thymikee This is happening inconsistently so its really hard to reproduce it. example:
following runs by selecting single file from tests ( option p )

• console.log('pantz') (works)
• change console.log(myObject) (not working)
• change it to fit (not working)
• change to console.log('pantz') (not working)
• change fit to it (not working)
• restart jest (not working)
• change it to fit (working)

Now I tried to replicate same steps and the result is inconsistent.

Provide a sample repo where it isn't working so that the JEST guys can help debug this. @kresli

There is plenty of user-error possibilities as well, mostly missing await or otherwise async console.log's.

I'll try find a time to reproduce this then. Until then I found my logs are eaten by results as you can see from bellow. Before FAIL appear you can see my 2 logs there. And also its worth to mention only 2 logs are removed. If I add 10 logs under each other, 8 would be shown. I think that's a good start :)

Meantime, if you need a catch-all fix that just works, you can use something like winston to log to both file and console. Even if your console messages don't show, they are written to file.

With winston you can configure what you want logged where and it supports multiple transports, and transports you can implement yourself.

const logger = winston.createLogger({
  level: "verbose",
  format: winston.format.json(),
  defaultMeta: {},
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: "combined.log" }),
  ],
});

logger.error(stuff)

Maybe you can even do something dirty like overriding console.* globally to winston's logger.

@kresli what version is your jest? That looks like v23 behavior

This keeps happening to me with jest v^24.6.0 and node v10.14.2. Any idea why?

@yaelz This is a stubbern issue that is commonly caused by user error but also has a history of hard to reproduce bugs.

I think it would really help the contributors to provide a reproducable case by providing an example repo or to provide another way to reproduce the issue.

Thanks for the quick response!
That'll be hard because the current repo is private in my org... I'll let you know if I get to it :)

This keeps happening to me with jest v^24.6.0 and node v10.14.2. Any idea why?

I recently upgrade some dependencies in a project and I don't have any issue, I face this one months ago, but it was solved in newer versions I believe...

Can you please share the versions you're using now, when it's solved?

On Mon, Aug 5, 2019 at 12:43 PM Norman Enmanuel notifications@github.com
wrote:

Thanks for the quick response!
That'll be hard because the current repo is private in my org... I'll let
you know if I get to it :)

I recently upgrade some dependencies in a project and I don't have any
issue, I face this one months ago, but I was solved in newer versions I
believe...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/jest/issues/3853?email_source=notifications&email_token=AB6F4PAE3CHUMEBP7IYXRPLQC7Y2DA5CNFSM4DPZ3JSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RI3PY#issuecomment-518163903,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB6F4PFXDSRHBW5CMTT2DKDQC7Y2DANCNFSM4DPZ3JSA
.

Can you please share the versions you're using now, when it's solved?

Sure:

jest

^24.8.0

node -v

v10.16.0

And this are some npm scripts that I use to run both, e2e, integration, unit and acceptance:

"scripts": {
  "test": "NODE_ENV=test npm run test:unit && npm run test:integration:both",
  "test:unit": "NODE_ENV=test jest --config test/jest.config.unit.js --detectOpenHandles",
  "test:integration": "NODE_ENV=test MOCK=false jest --config test/jest.config.integration.js --runInBand --detectOpenHandles",
  "test:integration:mock": "NODE_ENV=test MOCK=true jest --config test/jest.config.integration.js --runInBand --detectOpenHandles",
  "test:integration:both": "NODE_ENV=test npm run test:integration:mock -- --coverage; npm run db:migration:test; npm run test:integration -- --coverage;",
  "test:report": "open docs/test/report/index.html",
  "test:report:coverage": "open docs/test/coverage/lcov-report/index.html"
}

An this is the jest.config:

"use strict";

module.exports = {
  "bail": true,
  "verbose": false,
  "collectCoverage": false,
  "expand": true,
  "testURL": "http://localhost:3000/",
  "coverageDirectory": "./docs/test/coverage",
  "testEnvironment": "node",
  "rootDir": "../",
  "setupFilesAfterEnv": [
    "./test/jest.setup.js"
  ],
  "jest.showCoverageOnLoad": true,
  "watchPathIgnorePatterns": ["node_modules"],
  "transform": {
    "^.+\\.js$": "babel-jest",
    '^.+\\.tsx?$': 'ts-jest',
  },
  "reporters": [
    "default",
    ["./node_modules/jest-html-reporter", {
      "pageTitle": "...",
      "outputPath": "./docs/test/report/index.html",
      "includeFailureMsg": true,
      "sort": "titleAsc",
      "dateFormat": "yyyy-mm-dd HH:MM:ss"
    }]
  ]
};

Hope it helps.

I'll try find a time to reproduce this then. Until then I found my logs are eaten by results as you can see from bellow. Before FAIL appear you can see my 2 logs there. And also its worth to mention only 2 logs are removed. If I add 10 logs under each other, 8 would be shown. I think that's a good start :)

@kresli What is the status bar and time output that you have here? When I run my test suite, I see _RUN HARNESS test-harness/index.js_ and nothing else until everything runs. I then see my console.log message at the very end and the line with _RUN HARNESS..._ changes to _ HARNESS...._

Update: please ignore, turned out to be an issue in my code

Still facing this with node v12.16.1, jest 25.5.4, typescript 3.8.3 on MacOS. Tried the recommendations of using --runInBand, disabling/enabling verbose, using --silent=true, it didn't help.