Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Diff doesn't be displayed when object has Symbol value #2089

Closed
ryym opened this issue Feb 3, 2016 · 6 comments
Closed

Diff doesn't be displayed when object has Symbol value #2089

ryym opened this issue Feb 3, 2016 · 6 comments

Comments

@ryym
Copy link
Contributor

ryym commented Feb 3, 2016

When I assert an object that has a Symbol value, the test doesn't display diff even if it fails. For example, the following test fails without generating diff.

// test.js
const assert = require('assert');

it('should generate diff', () => {
  const obj = { type: Symbol('foo') };
  assert.deepEqual(obj, { type: null });
});

result:

mocha-symbol-before

Then I found the stringify function in lib/utils throws a following error when the argument object has a Symbol value.

TypeError: Cannot convert a Symbol value to a string

environment:

  • mocha: v2.4.5
  • node: v4.2.2
@glenjamin
Copy link
Contributor

I just ran into this, the json-stream and tap reports seem to hand this ok, so it's definitely a reporter problem - although the lack of an error is slightly more worrying

@ryym
Copy link
Contributor Author

ryym commented Feb 6, 2016

It seems the reporters like dot and spec which use this function cause this problem. The function generates diff by util.stringify() to convert Symbol to string and throws the error.
I sent PR for this issue :)

@glenjamin
Copy link
Contributor

Good stuff, is it possible to fix the black-holed error too?

@ryym
Copy link
Contributor Author

ryym commented Feb 6, 2016

is it possible to fix the black-holed error too?

Hmm, I don't know how to fix this. My PR just adds handling of Symbol values, so it does nothing about the black-holed error. But as you say, it should be fixed too.

@glenjamin
Copy link
Contributor

I've created a draft PR which attempts to solve the swallowed-error problem: #2096

@ryym
Copy link
Contributor Author

ryym commented Feb 7, 2016

Great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants