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

"Unable to get property toString" in all failed sinon-chai expectations #64

Open
thehig opened this issue Jun 1, 2015 · 17 comments
Open

Comments

@thehig
Copy link

thehig commented Jun 1, 2015

I've been using Mocha, Chai and Sinon inside of WinJS of late, and I've noticed a little odd behavior when a test fails using sinon-chai formatted expectations.

When an expectation fails using a chai formatted expectation, I get the AssertionError as expected.
However, performing the same test using sinon-chai formatted expectation returns an error (image attached)

I have put together a test spec that illustrates this issue inside my testrunner environment which is based on the work of Christopher Bennage.

The one thing I've noticed is that I'm not specifically setting chai.use("sinon-chai") anywhere, although even when I do I get the exact same set of errors.

image

@domenic
Copy link
Collaborator

domenic commented Jun 1, 2015

Can you list the sinon and chai and sinon-chai versions, and produce a small repro script?

@thehig
Copy link
Author

thehig commented Jun 1, 2015

Far as I know I've everything up to date:
Sinon - 1.15.0
Chai - 2.1.0
Sinon-chai - Don't see a version number, but it's the latest.

As far as producing a small script, unfortunately because I'm working in the WinJS environment there's a lot of boilerplate stuff.

The repo linked in Spectrum can be set to self-test by changing the specRunner in default.js to var specRunner = new Hilo.SpecRunner({ src: "js", specs: "specs", helpers: "js/helpers" }); and running the project.

This will require a Windows 8 computer. (edit: and Visual Studio)

@domenic
Copy link
Collaborator

domenic commented Jun 1, 2015

Can you try downgrading to Sinon 1.14.1 to see if that helps? I haven't tested with 1.15.0 and it contains changes that seem relevant.

@domenic
Copy link
Collaborator

domenic commented Jun 1, 2015

In terms of code snippets, can you at least post a JS file containing the minimal test setup required for the "should fail the test with an appropriate message (sinon-chai)" test, and nothing else?

@thehig
Copy link
Author

thehig commented Jun 1, 2015

I tried Sinon 1.14.1 and got the same error. I can try and strip the project down to it's bare essentials for you, but it won't be a single JS file unless I test this outside the WinJS environment. I'll get back to you

@thehig
Copy link
Author

thehig commented Jun 1, 2015

I've stripped the program down into a node app that runs the same file I linked above and it passes, or rather errors appropriately.

I'll try build a stripped down version that uses WinJS next, but will you even be able to test it?

@domenic
Copy link
Collaborator

domenic commented Jun 1, 2015

Not really. I was hoping that if I saw the actual code involved I could work by inspection, but the Node app doesn't seem to be doing anything wrong.

Maybe try a similar example in IE11?

@thehig
Copy link
Author

thehig commented Jun 1, 2015

I've been looking into stripping out the "unnecessary" bits from the WinJS project, but the truth is it's fairly intricate. I got the original project from here and it's worked fine with the other libraries I've needed, specifically sinon.

The thing is, the wrapper project is really just script injectors and such that pull in your js and spec files from another folder, configures Mocha/Chai and runs your tests.

I'll try and get a browser version working but I have this sneaking suspicion that this is going to be a WinJS platform type problem.

@domenic
Copy link
Collaborator

domenic commented Jun 1, 2015

I'm hopeful that it's a problem with the Chakra JS engine that's shared between IE11 and WAHost.

@thehig
Copy link
Author

thehig commented Jun 1, 2015

Pieced it together into a (rather disgusting) single HTML page using CDNs and whatnot and what do you know: same error!

Only happens in IE as well. Tested on Chrome and Firefox on Windows

image

@domenic
Copy link
Collaborator

domenic commented Jun 1, 2015

Yesss. I'll try to debug tonight then when I get home from work.

@thehig
Copy link
Author

thehig commented Jun 1, 2015

No problem, thanks. Let me know if I can help any further.

I'm just relieved I (may not) have to bail on yet another useful feature because I'm limited to working in WinJS

@domenic
Copy link
Collaborator

domenic commented Jun 2, 2015

I got a chance to start debugging through this and it's a crazy one. No solution yet but it seems like Chai's formatValue function fails on Sinon spies in interesting ways.

On IE11 it notices the createSpyCall key and tries to format that. However in doing so it ends up calling toString() on that, and apparently createSpyCall has a custom toString that is broken in this scenario for some reason.

In Chrome as far as I can tell it doesn't even notice the createSpyCall key.

I'd encourage you to debug into this yourself and see if you can help me out on this... very interesting.

Might be able to get a more minimal repro (without sinon-chai involved at all) with something like

chai.use(function (chai, utils) {
  utils.inspect(sinon.spy());
});

Haven't tried though; have to run to dinner.

@thehig
Copy link
Author

thehig commented Jun 3, 2015

I'll take a look after work if I get a chance. Thanks

@marian-r
Copy link

Any updates on this?

@thehig
Copy link
Author

thehig commented Aug 28, 2015

Sorry, I didn't get a chance to dive into this. My attention was diverted elsewhere

@markrian
Copy link

I encountered this in the test suite of https://github.com/blakeembrey/simulate-event. The very first test was failing with this error on IE11. I 'fixed' the issue by appending the fixture element to the DOM, and at first, it wasn't in the slightest bit clear to me why it worked.

But, thinking about it further... there was this call in the test in question:

expect(spy).to.have.been.calledOnce;

which, in attempting to fix the bug, I changed to:

expect(spy.callCount).to.equal(1);

which made the test fail in a different way: it turned out that the spy was never called!

So, probably due to another IE bug, by adding the fixture element to the DOM, the spy ended up getting called (as an event handler for that fixture element), and then the test passed with the original form:

expect(spy).to.have.been.calledOnce;

tl;dr: this bug seems to happen when for some reason the spy hasn't actually been called.

markrian added a commit to markrian/simulate-event that referenced this issue Nov 23, 2015
It's not clear why this fixes the test; the actual error is known and not
fixed/understood: chaijs/sinon-chai#64
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

4 participants