Why so loud, jest?
Why
Jest by default prints all console.log (warnings, errors, etc) messages to the console. That's great - it helps you understand what's going on in your code when tests run.
The problem starts when your repository grows. You get a mixture of hundreds of logs without being able to connect them to specific tests.
You might be able to use the logs, but there is as big of a chance that they will confuse you (you will think you found a log related to the test you are interested in, but it might be from a different one).
You could just turn all the noise, to at least have a nice output. (especially on CI, no one wants to scroll through tens of pages of Jenkins beautiful UI ;-) )
But that way if something fails, you lose an important debugging tool. Maybe the test does not fail locally, and the logs would make it trivial to understand what happened? But now you have to disable all but the failing test, re-enable logs... nightmare!
With this tiny plugin, you will be able to see ONLY RELEVANT console messages. That means - if all your tests pass, you have a beautiful jest tests report. If something fails - you see logs only for the test that failed!
How
Install this package:
yarn add why-so-loud-jest -D
Add it to your jest.config, with the verbose option
we are setting verbose even though we do not want the logs to be there in most cases
nonetheless when they are needed we want a nice, verbose report with a stack trace.
If you decide to do this you should probably follow the next step as well.
setupFilesAfterEnv: ['why-so-loud-jest'],
verbose: true
Enjoy much quieter jest!
Fix for wrong console messages stack traces
The downside of doing so will be that jest will show the wrong stack traces for the messages. Sad! :-(
If that starts bugging you, there is an option.
Now run npx why-so-loud-jest at the root of your package.
That will create patches for jest that will fix the problem. Follow the instruction displayed by the tool or here:
Please add postinstall script to your package.json:
"scripts": {
"postinstall": "patch-package"
}
install it:
npm i patch-package
if you use yarn:
yarn add patch-package postinstall-postinstall
(check https://www.npmjs.com/package/patch-package documentation)
run it once manually:
npx patch-package
Credit
The code was inspired by the https://stackoverflow.com/questions/58936650/javascript-jest-how-to-show-logs-from-test-case-only-when-test-fails thread, in particular, @casualcoder and @Finesse
Let me know if you have any questions or thoughts in the comments below.
Let us help you on your journey to Quality Faster
We at Xolvio specialize in helping our clients get more for less. We can get you to the holy grail of continuous deployment where every commit can go to production — and yes, even for large enterprises.
Feel free to schedule a call or send us a message below to see how we can help.
Add types to your AWS lambda handler
Lambdas handlers can be invoked with many different, but always complex, event arguments. Add to that the context, callback, matching return type and you basically start listing all the different ways that your function can fail in production.
How to expose a local service to the internet
From time to time you might need to expose your locally running service to the external world - for example you might want to test a webhook that calls your service. To speed up the test/development feedback loop it would be great to be able to point that webhook to your local machine.
For loops in JavaScript (vs _.times)
From time to time I still see a for loop in JavaScript codebases. Linters are frequently angry about them. Let's see how we can replace them.