Testcafe adds own logging statements to the browser console

[joma74]

What is your Test Scenario?

Check with testcafe if the application adds certain log statements to the browser console

What is the Current behavior?

testcafe adds own logging statements to the browser console

What is the Expected behavior?

testcafe does not add own logging statements to the browser console. See those on the screenshots.
P.S. They are not testcafe's logging statement of level failure or error, which i would else very much prefer to stay. Else if it is a feature of testcafe, then make it a planned feature with on/off option. I am very much a fan of logging, better noisy than failing silently. But then in a mangeable way. Plus explain how to interpret that logging statements

What is your web application and your TestCafe test code?

git clone https://github.com/joma74/angular-ultimate-pro.git --branch testcafe-0.23.1-logging-issue --single-branch testcafe-0.23.1-logging-issue

See also https://travis-ci.org/joma74/angular-ultimate-pro/builds/452767145

Your complete test report:

``` Browser: Firefox 63.0.0 / Ubuntu 0.0.0 Screenshot: /home/joma/entwicklung/nodews/angular-ultimate-pro/target/reports/screenshots/actual/Index_Page_Test/console_has_messages/Firefox_63.0.0_Ubuntu_0.0.0/errors/1.png 32 | 33 | const { log, error } = await t.getBrowserConsoleMessages() 34 | await t.expect(error.length).eql(0, JSON.stringify(error)) 35 | await t 36 | .expect(log[2]) > 37 | .eql('Login {"email":"","password":"","rememberMe":true}') 38 |}) 39 | 40 |const testName2 = "can_destroy_component" 41 | 42 |test(testName2, async (t) => { at eql (/home/joma/entwicklung/nodews/angular-ultimate-pro/src/tests/index-test.js:37:6) 2) AssertionError: expected '[object Object] object' to deeply equal 'Login {"email":"","password":"","rememberMe":true}' Browser: HeadlessChrome 70.0.3538 / Linux 0.0.0 Screenshot: /home/joma/entwicklung/nodews/angular-ultimate-pro/target/reports/screenshots/actual/Index_Page_Test/console_has_messages/HeadlessChrome_70.0.3538_Linux_0.0.0/errors/1.png 32 | 33 | const { log, error } = await t.getBrowserConsoleMessages() 34 | await t.expect(error.length).eql(0, JSON.stringify(error)) 35 | await t 36 | .expect(log[2]) > 37 | .eql('Login {"email":"","password":"","rememberMe":true}') 38 |}) 39 | 40 |const testName2 = "can_destroy_component" 41 | 42 |test(testName2, async (t) => { at eql (/home/joma/entwicklung/nodews/angular-ultimate-pro/src/tests/index-test.js:37:6) ]]> </failure> ```

Screenshots:

Steps to Reproduce:

1. git clone https://github.com/joma74/angular-ultimate-pro.git --branch testcafe-0.23.1-logging-issue --single-branch testcafe-0.23.1-logging-issue
2. yarn
3. yarn ci
4. See the test failures

Your Environment details:

• testcafe version: 0.23.1
• node.js version: v10.13.0
• command-line arguments: testcafe 'firefox:headless,chrome:headless --no-sandbox --disable-gpu' -S -s $npm_package_config_screenshots -p $npm_package_config_screenshot_path_pattern -r spec,xunit:$npm_package_config_reports/report.xml src/tests/index-test.js
• browser name and version: HeadlessChrome 70.0.3538, Firefox 63.0.0
• platform and version: Ubuntu 16.04.5 LTS
• other:

[ronanmulvaney]

Seeing the same breaking our tests and capturing of any console.log output

[VasilyStrelyaev]

I have managed to replicate this behavior. Our team will research it and find a suitable solution if any.

[AndreyBelym]

It's my fault. I added this line directly to the replicator package installed on my machine and forgot about it. When I executed npm install before publishing, it didn't go away because module's version was actual. Then webpack added modified replicator's module code to the client script's bundle, and the package was published with the contaminated script bundle.

We have to publish a new version ASAP and modify the pre-publish script to clean and reinstall modules before building the package.

[AndreyBelym]

I've published the [email protected] version with the fix. I can't reproduce the problem on my machine with this version. Could you please try it in your environments? Our team will test this pre-release version and publish the stable [email protected] release on Monday.

[ronanmulvaney]

Testing with v0.23.2-alpha.1 solves the issue for me here.

[joma74]

LGTM 👍

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or feature requests. For TestCafe API, usage and configuration inquiries, we recommend asking them on StackOverflow.