How to turn off console logging

[brian-mann]

I see that this console logging is forwarded via this line.

What's the easiest way to remove this? Would a config option have to be exposed?

I'm basically running my tests while using mocha in the browser alongside of phantomjs, so I can't remove them in my build process (which I know would be the easiest way). I was hoping just to have them removed only while running via phantom js.

Thanks.

[nathanboktae]

Yeah seems reasonable to expose a config switch to turn this off.

[nathanboktae]

Thinking about this more, it's problematic as a lot, maybe most, reporters use console.log to output and there is no way to differentiate that output. It's already confusing enough with --file that pipes only process.stdout.write.

What reporter are you using? And why can't you take the console.log calls out of your code?

[frontierpsycho]

I have the same problem. I can't remove the console.log calls out of the code, there might even be log calls in libraries etc.

[nathanboktae]

I can't remove the console.log calls out of the code

Why? It's unprofessional to leave console.log statements in production code, not to mention in older IEs console is undefined if you didn't push F12 and will throw.

Like I said above, most reporters use console.log to produce it's output, so there's no way to differentiate that output. My suggestion would be that if you have to keep it and the reporter of your choice uses console.log, you fork the reporter and use process.stdout.write instead of console.log for it.

[frontierpsycho]

I still think it's a rather unrealistic expectation by the test runner to require no console logging by the tests, to be able to report correctly. I could argue that it's unprofessional, but that would be quite a pointless argument, now, wouldn't it?

The important thing is you disagree and you won't fix this. Thanks for the suggestion.

[metaskills]

Is this request visual or does console logging break things? Can someone show me a failing test scenario?

[frontierpsycho]

Reporters like xunit, for example, attempt to produce XML, and if that gets randomly sprinkled with logging output, sometimes the xunit report becomes invalid, I think. In general, reporters that need to produce a specifically formatted file will break.

Apart from that, there's also the visual thing. Mocha-phantomjs outputs a line to mark the beginning of a test, then the test outputs some logging, and mocha-phantomjs tries to go back and amend its previously output line with success or failure, and it fails, so it outputs the success of failure line after the test's logging. This messes up test reporting very much, making it tiresome to try to read it.

[metaskills]

I can really see both sides to this. If it were me, I would put all my logging behind a common interface that could easily be disabled under CI environments. I feel this is what most big frameworks and those that choose too log do. I did a quick search and feel that logger objects with levels are the real way to go and that this problem solves itself when best practices are followed. Thoughts?

[frontierpsycho]

If we were in the Java world, where configurable logging is practically ubiquitous, I'd tend to agree with you more. In JS, it isn't.

In any case, I think the test runner should be able to handle test logging, and not assume that the tests don't log anything. That's too harsh and it makes the tool's usability (from the point of view of the developer) potentially cumbersome. If it's too tricky to implement, I understand skipping it, but arguing that "production code shouldn't log anyway" is off the mark.

[metaskills]

"production code shouldn't log anyway" is off the mark.

Perhaps, it should be up to the developer, but it also means that they need to be smart about it too and anyone that would is going to use a simple logger object that detects if at the minimum if console.log is present.

I think this make my point above and I do disagree that configurable logging is the defacto. This is why @nathanboktae said that distro code like jQuery etc are not going to have log gin in them. If you want to log, then you should carry the baggage of what that means and use a logger object. A quick google search shows that many do. Tho I am open to seeing a PR for this feature too.

[frontierpsycho]

Cool, then. If there's time, I just might submit one. Thanks.

[nathanboktae]

The important thing is you disagree and you won't fix this.

No you missed the point where it's not possible to fix it as suggested. Reporters use console.log and random code uses console.log. Both are pieces of code that runs in the client browser. the built in Mocha reporters are compiled in to it.

Not to mention I gave you another alternate solution of forking the reporter. Why is that not an option? will take you 2 mins to do.

btw I have tried to resolve this issue before too - see mochajs/mocha#1068

[frontierpsycho]

Sorry, by

Thanks for the suggestion.

I meant I'll try it. So it is an option, but I still thought it makes sense for mocha-phantomjs to support this without tweaking the reporter. I'm not sure how to do it, and I know what you mean, that both the reporter and the tests use console.log. Still, there might be a way to separate them, if I have time to look into it I'll see what I come up with.

[nathanboktae]

The TL;DR is if you need your reporter output separated, use a reporter that uses process.stdout.write and use the --file option to output it, and then you can pipe stdout from mocha-phantomjs wherever you want.