test: test-assert.js fails locally

[vsemozhetbyt]

• Version: 10.0.0 (master)
• Platform: Windows 7 x64
• Subsystem: test. assert

Testing the #18904 locally, I've got this not related error, which I can also reproduce with the last nightly:

assert.js:74
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: 'The expression evaluated to a falsy value:\r\n\r\n  assert((() => \'string\')()\n      // eslint-disable-next-line\n      ==... strictEqual 'The expression evaluated to a falsy value:\r\n\r\n  assert((() => \'string\')()\r\n      // eslint-disable-next-line\r\n    ...
    at Object.innerFn (test\common\index.js:701:16)
    at expectedException (assert.js:406:19)
    at Function.throws (assert.js:451:16)
    at Object.expectsError (test\common\index.js:723:12)
    at Object.<anonymous> (test\parallel\test-assert.js:642:8)
    at Module._compile (module.js:666:30)
    at Object.Module._extensions..js (module.js:677:10)
    at Module.load (module.js:577:32)
    at tryModuleLoad (module.js:517:12)
    at Function.Module._load (module.js:509:3)

It seems reasonable: this fragment uses \n on all systems, while this fragment uses \r\n on Windows.

Why does not this test fail on CI?

[BridgeAR]

That is a very interesting case. It seems like the parsed output from acorn is always using \n. The test uses the OS EOL and tests against this.
Is there any chance that the acorn version is not the same for you as the one in the CI? Tomorrow I will check what acorn will use a default.

[vsemozhetbyt]

Is there any chance that the acorn version is not the same for you as the one in the CI?

I cannot think of any cause for this)

@nodejs/platform-windows, can anybody else check the test locally or suppose any causes for this difference?

[vsemozhetbyt]

Still fails.

[bzoz]

Pipeing test output fixes this, node --expose-internals test\parallel\test-assert.js | more passes.

[targos]

I also experienced this on Windows locally.

[bzoz]

I guess the issue is here:

node/lib/internal/errors.js

Lines 403 to 407 in dd03709

	if (process.stdout.getColorDepth() !== 1) {
	blue = '\u001b[34m';
	green = '\u001b[32m';
	white = '\u001b[39m';
	red = '\u001b[31m';

When the stdout is a TTY, colors are added to the error message and this confuses test runner. We could add a way to disable colors, or make the test expect them. Or, we can make the test spawn itself with piped output, so the error messages will get generated without colors.