-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jest eats up all console.log messages during debugging #8208
Comments
Jest was doing this the other day for me and then it randomly stopped immediately printing logs. I know this because I'm trying out using jest for some simple data tests that do 500+ http calls. The first few tests I wrote it was printing the logs as it went. Now it waits until the test is complete. As far as I know I didn't change any config in between so I really don't understand why it changed. |
Furthermore, Jest doesn't seem to output messages at all if the test fails, which makes debugging broken tests quite painful. it('should do stuff', () => {
console.log('Hello World')
expect(1).toBe(2)
})
There's no "Hello World" to be seen anywhere |
Just to clarify - is this when in watch mode? And which versions of Jest are you using? |
I just tried it again in a fresh project with version 24.7.1 and the "Hello World" example does output the message to console. Huh, I guess I must've used an older version or misconfigured something when I tried this before. Anyways, it's working fine for me now. Edit: can't remember whether I was using watch mode or not when I made my previous comment. |
➕1️⃣ This is really crucial for TDD to be able to Using Jest Jest config: module.exports = {
transform: {
'^.+\\.ts$': 'ts-jest',
},
testRegex: '.+\\.ts',
moduleFileExtensions: ['ts', 'js'],
rootDir: 'tests',
testEnvironment: "node",
} Command that is run: npx jest --runTestsByPath ${pathToTestFile} --colors --verbose=false |
+1 |
As a temporary workaround, you can set
|
Are you seeing the same issue if you run with |
console.log was not working with v23.0.2. console.log messages are working again with v25.4.0 (current latest). The console.log messages were ONLY appearing when attached to a debugger in v23.0.2 |
Rather than a feature request, I would call this a serious bug. In the best case, I would consider this a huge overreach by a library to swallow console output. What is the workaround for situations where process exits 1 and needs to print an error? Swallowing it makes issues very expensive to fix in continuous testing suites. None of the proposals work for me. Running |
Is it so hard to fix console.log issues? It's pretty frustrating to waste time because for some reasons jest won't display necessary logs and there is no workarounds about it at all. |
Looks like when you run jest via |
I'm debugging some code that takes a while to run (if it finishes at all 😢) so, like the users above, being able to specify that I want my logs to be printed "live" is pretty important. None of the workarounds listed above are working for me, but I've found one that does: The downside is that you lose |
+1 to everything here |
I would expect that console output be held for purposes of parallelization, but when |
+1. Now is 2021, still open? |
+1 |
1 similar comment
+1 |
I'm going to dig into the code and see if I can figure out why it does it. |
I thought for sure the problem would be use of the BUT. That logic is short-circuited when the verbose flag is passed. I put a debugger in to be sure I wasn't getting the BufferedConsole after passing the verbose flag, and indeed I am not. So time to turn the attention elsewhere. Fortunately I think in the course of the above investigation I found the next thing to investigate, which is stdio wrapping in the default reporter. Note that that code is actually monkey patching process.stdio.write! It writes after a debounce period. I feel reasonably confident that if this logic can also be bypassed this bug can be considered resolved. There is already a separate verbose reporter which inherits from the default reporter. It inherits the default reporter's stdio wrapping, but I'm inclined to think given the evidence of attempts to have verbose mode punch through buffering logic, this is the real root cause. I presume someone added the buffering to the default reporter without considering that the verbose reporter would also gain the behavior, breaking an untested use case. Let me write up a PR and see if anyone takes note. |
Also it isn't necessary to read any config flag other than |
@conartist6 Why #11054 is not being merged? |
@cc-ebay hopefully there is now no longer any reason. |
I have the same bug but not during debugging, but during simple run. Using jest ^24.9.0. This bug makes my library built over jest not work and not output logs if the expect doesn't pass. Fix that please! |
@MetaMmodern are you able to test to find out if the fix in #11054 solves the issue you have? |
Sorry, I'm hot sure how to install a pull request version of a package(( |
I managed this to work with |
Maybe there's a better way, but you can just patch the code in |
Okay, I'll try tomorrow. |
It says But hey, the file is readible. I'll just go edit the file myself and check what happens)) |
@conartist6 Hi, I've managed to apply your changes from pull request manually and it seems like console logs are disabled completely after those actions, the only thing is shown for me is that |
Oh that's my bad. I did some hand editing to get the essential part of the fix to apply without any of the other changes, and I missed something: I forgot to change |
If it is your belief that that my PR should not be merged, then you must show some kind of repro of what is wrong. At the moment all I can say is that I suspect you made a mistake in your debugging. A couple things you say strike me as odd. First, you say my change fixed the default reporter. My change does not touch the default reporter at all. Second you say that my change is causing all output to disappear from the verbose reporter, but those seem like the exact same symptoms you were seeing before you changed Just to avoid any confusion at all, that method should read: _wrapStdio(stream) {
const write = stream.write.bind(stream);
stream.write = (chunk) => {
this._clearStatus();
write(chunk);
this._printStatus();
return true;
};
} |
Also note that you may be using the verbose reporter even without |
I've analyzed your PR and the only difference is:
Also you say that your change does not touch the default reporter at all. That is strange, cause in your PR #11054 I see those files changed... |
Yes there are some changes in the PR that aren't needed for the minimal fix. Those aren't just variable names, they're methods defined by the base class. You can't just call whatever name you want, you have to call the method that exists, which is |
That's what i say, I did not change them in the base class as you did, so I just left them as they are. Look, it is kinda hard for me to create an example of what's not working, so maybe we could contact somewhere else and have a quick call whereI'd show you the code and check what's wrong? If this is an option for you--let me know, I'll contact you on gmail. |
Respond on gmail. My address is on my profile. I know you didn't change those names in the base class, but you're still calling them by the |
https://github.com/facebook/jest/releases/tag/v27.2.5 There are probably still cases that doesn't work. If so, please open up a new issue (with a reproduction) and link this issue rather than comment here. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
🚀 Feature Proposal
Currently Jest eats up all console.log/warn/error messages during debugging and I'm completely blind all the way through up until the test finishes.
I'd like to be able to enable Jest to spit out console.log messages immediately during debugging sessions.
Motivation
Being able to immediately see all console.log/warn/error messages while debugging unit tests in the debugger would enable all of us to observe the app behavior interactively.
The text was updated successfully, but these errors were encountered: