I'm trying to suppress a specific error in our Jest tests as we've got plans to resolve it later, but until then we don't want these errors potentially hiding any true errors.
The errors occur across the codebase so my current strategy is to rewire the console.error function in our jest setup file.
I've taken two different attempts, both almost working however now when they report a true error - they're adding a new line onto the error trace.
Attempt 1:
const originalError = console.error.bind(console.error);
jest.spyOn(global.console, 'error').mockImplementation((message) => {
if (
!message
.toString()
.includes(
'Warning: An update to SettingsPanel inside a test was not wrapped in act'
)
) {
originalError(message);
}
});
Attempt 2:
const { error } = console;
global.console = {
...console,
error: (errorMessage) =>
!errorMessage
.toString()
.includes(
'Warning: An update to SettingsPanel inside a test was not wrapped in act'
) && error(errorMessage),
};
Both of these will log a valid error - i.e. 'Warning: Each child in a list should have a unique "key"' - However instead of pointing me to the code with the issue it points me back here
console.error
Warning: Each child in a list should have a unique "key" prop.%s%s See https://reactjs.org/docs/lists-and-keys.html#keys for more information.%s
18 | .includes(
19 | 'Warning: An update to SettingsPanel inside a test was not wrapped in act'
> 20 | ) && error(errorMessage),
| ^
21 | };
at Object.error (jest.setup.js:20:12)
at printWarning (node_modules/react/cjs/react.development.js:315:30)
at error (node_modules/react/cjs/react.development.js:287:5)
at validateExplicitKey (node_modules/react/cjs/react.development.js:1630:5)
at validateChildKeys (node_modules/react/cjs/react.development.js:1656:9)
at Object.createElementWithValidation [as createElement] (node_modules/react/cjs/react.development.js:1806:7)
at src/js/components/SettingsPanel/DataListAutocompleter/DataListAutocompleter.tsx:85:13
I've searched and searched and all I can find are questions about silencing all errors or silencing a specific test - nothing I've found has helped me solve this.
Use failOnConsole in your setupFilesAfterEnv configuration.
You can configure this to silence some errors, and fail on others:
import failOnConsole from 'jest-fail-on-console'
failOnConsole({
silenceMessage: (errorMessage) => {
if (/'Warning: An update to .*? inside a test was not wrapped in act/.test(errorMessage)) {
return true
}
return false
},
})
This should silence ALL instances of that error. Everything else will go through, it will give you more lines, but should still preserve the original source of the error, underneath the line it adds.
I can't count the number of DOM elements on a site written in React.
/// <reference types="cypress" />
context('Checking all components', () => {
beforeEach(() => {
cy.visit('https://news-israel.com');
});
it('Checking posts', () => {
cy.get('.posts-wrapper').find('a').should('exist');
cy.get('.posts-wrapper').find('a').its('length').should('be.gte', 100);
});
});
In this case, it doesn't find the "a" tags because React rendering them asynchronously and dynamically.
The "post-wrapper" class finds, followed by an exception:
The following error originated from your application code, not from Cypress.
Cannot read property 'substr' of undefined
When Cypress detects uncaught errors originating from your application it will automatically fail the current test.
How to correctly count the number of elements in this case, so that you can "wait for the elements"?
The site I'm testing is in production - https://news-israel.com
The error is coming from the app itself, and ultimately should be fixed in the app source.
But see this note in the log
This behavior is configurable, and you can choose to turn this off by listening to the uncaught:exception event.
This links to an event handler you can use to debug. Add this to the top of the test to suppress the test failing when the error occurs.
Cypress.on('uncaught:exception', (err, runnable) => {
// returning false here prevents Cypress from
// failing the test
return false
})
Now the test works, provide you use the correct class posts-wrapper not post-wrapper.
If you are able to fix the source, the error comes from the react-typed library, which is used in BreakingNews.js at line 75
<Typed
strings={posts}
typeSpeed={15}
backSpeed={10}
backDelay={5000}
loop
/>
the posts variable is initially undefined, so you need a fallback value, e.g strings={posts || []}
To globally Handle Uncaught exceptions, Go to cypress/support/index.js and write:
Cypress.on('uncaught:exception', (err, runnable) => {
return false
})
Now to count the number of elements you do it via each() or by using Cypress.$
Using each():
cy.get('div.post-title').each((ele, list) => {}).then((list) => {
cy.log(list.length)
})
Using Cypress.$
cy.get('div').find('.post-title').then(ele => {
cy.log(Cypress.$(ele).length)
})
OR, As suggested by #Hiram
cy.get('div.post-title').then(ele => {
cy.log(Cypress.$(ele).length)
})
I've been running this Angular 5 app for a while with Google authentication and then this error suddenly appeared (both on prod and dev). Sign in is successful and I am getting a GoogleAuth object (I can get the user details), but then I get this error:
Uncaught TypeError: googleAuth.then is not a function
Here's the code block. _googleAuth is a service which calls init.
this._googleAuth.getAuth()
.subscribe(googleAuth => {
// TODO
console.log('user signedIn: ', googleAuth.isSignedIn.get()); // this returns true
const self = this;
googleAuth.then(function() { // error occurs here
if (googleAuth.isSignedIn.get()) {
...
}
...
I've updated the typings to:
"#types/gapi": "0.0.35",
"#types/gapi.auth2": "0.0.47",
Here's the getAuth function (which seems to still work):
public getAuth(): Observable<GoogleAuth> {
if (!this.GoogleAuth) {
return this.googleApi.onLoad().mergeMap(() => this.loadGapiAuth());
}
return Observable.of(this.GoogleAuth);
}
I've checked the typings and GoogleAuth.then is defined there. Why is it that I can get a GoogleAuth object but not call .then?
The Google docs for GoogleAuth.then are here: https://developers.google.com/identity/sign-in/web/reference#googleauththenoninit-onerror
I'm still not clear why this became an error now, but I found a possible solution. The TypeScript wrapper service was already calling .then after gapi.auth2.init, so it looks like I was calling it twice. I've removed that check and it seems to be working. I still have to run my test suite, but so far it looks promising.
I've set up Cucumber-JS and Grunt-JS within my solution.
My folder structure looks like this:
+ Project
+ features
- Search.feature
+ step_definitions
- Search_steps.js
+ support
- world.js
- package.json
- gruntfile.js
I've added a Cucumber-JS task in gruntfile.js:
// Project configuration.
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
cucumberjs: {
src: 'features',
options: {
steps: 'features/step_definitions',
format: 'pretty'
}
}
});
grunt.loadNpmTasks('grunt-cucumber');
grunt.registerTask('default', ['cucumberjs']);
And I've written out my feature file:
Feature: Search
As a user of the website
I want to search
So that I can view items
Scenario: Searching for items
Given I am on the website
When I go to the homepage
Then I should see a location search box
And my step definition file:
var SearchSteps = module.exports = function () {
this.World = require('../support/world').World;
this.Given('I am on the website', function(callback) {
callback.pending();
});
this.When('I go to the homepage', function (callback) {
callback.pending();
});
this.Then('I should see a location search box', function (callback) {
callback.pending();
});
};
And my world.js file:
var World = function (callback) {
callback(this);
};
exports.World = World;
But when I run grunt at the command-line, while it seems to see my features, it never seems to run any of the steps.
All I get is this:
Running "cucumberjs:src" (cucumberjs) task
Feature: Search
Scenario: Searching for items
Given I am on the website
When I go to the homepage
Then I should see a location search box
1 scenario (1 pending)
3 steps (1 pending, 2 skipped)
Done, without errors.
Cucumber doesn't seem to pay any attention to what I put inside the tests.
Even if I put some obvious logical bug in, e.g.:
this.Given('I am on the website', function(callback) {
var x = 0 / 0;
callback.pending();
});
It just ignores it and prints the above message.
The only way I can seem to get any error out of Cucumber is to put an outright syntax error in the step file. E.g. remove a closing bracket. Then I get something like this:
Running "cucumberjs:src" (cucumberjs) task
C:\dev\Project\features\step_definitions\Search_steps.js:14
};
^
Warning: Unexpected token ; Use --force to continue.
Aborted due to warnings.
What am I missing here?
As I said in my comments, everything is working as expected. Calling callback.pending() tells Cucumber your step definition is not ready yet and the rest of the scenario should be ignored for now.
Change that to callback() to tell Cucumber to move to the next step in the scenario. If you want to notify Cucumber of a failure, pass an error to that callback or throw an exception (I don't recommend that though):
callback(new Error('This is a failure'));
HTH.
Have you tried this?
this.World = require("../support/world.js").World;
I currently have this JS statement everywhere in my code:
window.console && console.log("Foo");
I am wondering if this is costly at all, or has any negative side-effects in production.
Am I free to leave client-side logging in, or should it go?
EDIT: In the end, I suppose the best argument I (and anyone else?) can come up with is that there is a possibly non-negligible amount of extra data transferred between the server and the client by leaving logging messages left in. If production code is to be fully optimized, logging will have to be removed to reduce the size of javascript being sent to the client.
Another way of dealing with this is to 'stub' out the console object when it isn't defined so no errors are thrown in contexts that do not have the console i.e.
if (!window.console) {
var noOp = function(){}; // no-op function
console = {
log: noOp,
warn: noOp,
error: noOp
}
}
you get the idea... there are a lot of functions defined on the various implementations of the console, so you could stub them all or just the ones you use (e.g. if you only ever use console.log and never used console.profile, console.time etc...)
This for me is a better alternative in development than adding conditionals in front of every call, or not using them.
see also: Is it a bad idea to leave "console.log()" calls in your producton JavaScript code?
You should not add development tools to a production page.
To answer the other question: The code cannot have a negative side-effect:
window.console will evaluate to false if console is not defined
console.log("Foo") will print the message to the console when it's defined (provided that the page does not overwrite console.log by a non-function).
UglifyJS2
If you are using this minifier, you can set drop_console option:
Pass true to discard calls to console.* functions
So I would suggest to leave console.log calls as they are for a most trickiest part of the codebase.
If minification is part of your build process, you may use it to strip out debug code, as explained here with Google closure compiler: Exclude debug JavaScript code during minification
if (DEBUG) {
console.log("Won't be logged if compiled with --define='DEBUG=false'")
}
If you compile with advanced optimizations, this code will even be identified as dead and removed entirely
Yes. console.log will throw an exception in browsers that don't have support for it (console object will not be found).
Generally yes, its not a great idea to expose log messages in your production code.
Ideally, you should remove such log messages with a build script before deployment; but many (most) people do not use a build process (including me).
Here's a short snippet of some code I've been using lately to solve this dilemma. It fixes errors caused by an undefined console in old IE, as well as disabling logging if in "development_mode".
// fn to add blank (noOp) function for all console methods
var addConsoleNoOp = function (window) {
var names = ["log", "debug", "info", "warn", "error",
"assert", "dir", "dirxml", "group", "groupEnd", "time",
"timeEnd", "count", "trace", "profile", "profileEnd"],
i, l = names.length,
noOp = function () {};
window.console = {};
for (i = 0; i < l; i = i + 1) {
window.console[names[i]] = noOp;
}
};
// call addConsoleNoOp() if console is undefined or if in production
if (!window.console || !window.development_mode) {
this.addConsoleNoOp(window);
}
I'm pretty sure I took much of the above addConsoleNoOp f'n from another answer on SO, but cannot find right now. I'll add a reference later if I find it.
edit: Not the post I was thinking of, but here's a similar approach: https://github.com/paulmillr/console-polyfill/blob/master/index.js
var AppLogger = (function () {
var debug = false;
var AppLogger = function (isDebug) {
debug = isDebug;
}
AppLogger.conlog = function (data) {
if (window.console && debug) {
console.log(data);
}
}
AppLogger.prototype = {
conlog: function (data) {
if (window.console && debug) {
console.log(data);
}
}
};
return AppLogger;
})();
Usage:
var debugMode=true;
var appLogger = new AppLogger(debugMode);
appLogger.conlog('test');
Don't overcomplicate things! I personally use console.log all the time during development, it's just such a timesaver. For production i just add a single line of code (in the "production profile" in my case) that disable all logs:
window.console.log = () => {};
done ;)
This monkey patches window.console and replace the log function with an empty function, disabling the output.
This is good enough for me in most cases. If you want to go "all the way" and remove console.logs from your code to decrease bundle size, you have to change the way your js is bundled (e.g. drop console.logs with minifier or something)
Also I think you CAN actually make a strong point for leaving them in - even in production. It doesn't change anything for a normal user but can really speed up understanding weird "exotic-browser" problems. It's not like it's backend-logs that may contain critical information. It's all on the frontend anyway, not showing a log message because you are scared to reveal something a user shouldn't know really is only "security by obscurity" and should make you think why this information is even available on the frontend in the first place. Just my opinion.
Yes, its good practice to use console.log for javascript debugging purpose, but it needs to be removed from the production server or if needed can be added on production server with some key points to be taken into consideration:
**var isDebugEnabled="Get boolean value from Configuration file to check whether debug is enabled or not".**
if (window.console && isDebugEnabled) {
console.log("Debug Message");
}
Above code block has to be used everywhere for logging in order to first verify whether the console is supported for the current browser and whether debug is enabled or not.
isDebugEnabled has to be set as true or false based on our
environment.
TL;DR
Idea: Logging objects precludes them from being Garbage Collected.
Details
If you pass objects to console.log then these objects are accessible by reference from console of DevTools. You may check it by logging object, mutating it and finding that old messages reflect later changes of the object.
If logs are too long old messages do get deleted in Chrome.
If logs are short then old messages are not removed, if these messages reference objects then these objects are not Garbage Collected.
It's just an idea: I checked points 1 and 2 but not 3.
Solution
If you want to keep logs for sake of client-side troubleshooting or other needs then:
['log', 'warn', 'error'].forEach( (meth) => {
const _meth = window.console[meth].bind(console);
window.console[meth] = function(...args) { _meth(...args.map((arg) => '' + arg)) }
});
If the workflow is done using the right tools such as parcel/webpack then it's no longer a headache, because with the production build console.log is being dropped. Even few years earlier with Gulp/Grunt it could've been automated as well.
Many of the modern frameworks such as Angular, React, Svelte, Vue.js come with that setup out-of-the-box. Basically, you don't have to do anything, as long as you deploy the correct build, i.e. production one, not development which will still have console.log.
I basically overwrite the console.log function with the one what has knowledge of where the code is being run. Thus i can keep using console.log as I do always. It automatically knows that I am in dev/qa mode or in production. There is also a way to force it.
Here is a working fiddle.
http://jsfiddle.net/bsurela/Zneek/
Here is the snippet as stack overflow is intimated by people posting jsfiddle
log:function(obj)
{
if(window.location.hostname === domainName)
{
if(window.myLogger.force === true)
{
window.myLogger.original.apply(this,arguments);
}
}else {
window.myLogger.original.apply(this,arguments);
}
},
I know this is quite an old question and hasn't had much activity in a while. I just wanted to add my solution that I came up with which seems to work quite well for me.
/**
* Logger For Console Logging
*/
Global.loggingEnabled = true;
Global.logMode = 'all';
Global.log = (mode, string) => {
if(Global.loggingEnabled){
switch(mode){
case 'debug':
if(Global.logMode == 'debug' || Global.logMode == 'all'){
console.log('Debug: '+JSON.stringify(string));
}
break;
case 'error':
if(Global.logMode == 'error' || Global.logMode == 'all'){
console.log('Error: '+JSON.stringify(string));
}
break;
case 'info':
if(Global.logMode == 'info' || Global.logMode == 'all'){
console.log('Info: '+JSON.stringify(string));
}
break;
}
}
}
Then I typically create a function in my scripts like this or you could make it available in a global script:
Something.fail = (message_string, data, error_type, function_name, line_number) => {
try{
if(error_type == undefined){
error_type = 'error';
}
Global.showErrorMessage(message_string, true);
Global.spinner(100, false);
Global.log(error_type, function_name);
Global.log(error_type, 'Line: '+line_number);
Global.log(error_type, 'Error: '+data);
}catch(error){
if(is_global){
Global.spinner(100, false);
Global.log('error', 'Error: '+error);
Global.log('error', 'Undefined Error...');
}else{
console.log('Error:'+error);
console.log('Global Not Loaded!');
}
}
}
And then I just use that instead of console.log like this:
try{
// To Do Somehting
Something.fail('Debug Something', data, 'debug', 'myFunc()', new Error().lineNumber);
}catch(error){
Something.fail('Something Failed', error, 'error', 'myFunc()', new Error().lineNumber);
}