-
Notifications
You must be signed in to change notification settings - Fork 781
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
Integrations: Sinon with QUnit #1749
Comments
This ticket be of interest to you. I noticed your package at https://github.com/PrecisionNutrition/qunit-sinon-assertions, which seems to go further and even make the comparisons native to benefit from diffing. Awesome. It seems to still be a work in progress, with Ember CLI dependencies bundled. Is that right? I'd love to promote it on qunitjs.com when ready! |
FWIW, I've used Sinon a lot and usually just call Sinon directly without doing any real integration with QUnit. |
@Krinkle it seems they just released 1.0 a few weeks ago :) |
@Krinkle we've started trying to tackle this issue here: elwayman02/ember-sinon-qunit#529 The initial implementation just clobbers the pass/fail methods and calls
Can you explain the implications of this? I'd like to make sure that we're properly handling this integration in a way that makes sense for established QUnit and Sinon paradigms. |
@Krinkle Would you care to elaborate on what you're referencing by Thanks! |
@mwagz By "local assertion object" I was referring to the You might already know the next bit, but I'll add it for context:
If I understand correctly, the PR you linked would be calling The recommendation I hinted at, in my initial thought dump at the start of this issue, would be to either:
Then, from inside the beforeEach you can assign I'll also prioritize #1475 further, which would allow Ember to register its |
Hey @Krinkle just wanted to check in to see how progress was coming on this end. We're super excited about this work! |
Two micro optimisations: * Move the declaration of the hooks object to where the internal module is created more generally. Adding the property later seems confusing and was less optimal. * Move two utility functions from within processModule() to outside of it as they didn't use any of its scope and thus were needlessly being re-allocated for every registered test module. Clarity: * Move `module.hooks` and `module.stats` property definitions to the module object literal rather than creating them sometime later as dynamic properties. * Clarify that the unnamed module is not (and should not become) a "global module". I was thinking of doing this as a way to implement the upcoming global QUnit.hooks feature, but then remembered that these are two distinct concepts that I think are best kept separate. This is preparation for #1475, ref https://github.com/qunitjs/qunitjs.com/issues/161.
@elwayman02 Thanks for the poke. I spent today figuring out different approaches and settled on one. I've jiggled around some code in preparation for this, and hope to land and release the rest this coming week. |
Hey friends. I know this is a bit of an old issue, but I'm one of the devs that manages the qunit-sinon-assert packages. I wasn't being paged! I'll try and read over this issue later this week to see if there are improvements we could/should make to our package. |
@jherdman Thanks! I've since released the aforementioned global hooks. Docs at https://api.qunitjs.com/QUnit/hooks/. Let me know if you run into any issues. |
Looks like sinon does not currently allow the So QUnit will not know when things pass, only when they fail. |
Another one for the "Integrations" section (ref qunitjs/qunitjs.com#42), we can promote use of SinonJS.
Perhaps a very plain and simple way, could be like so:
With Sinon 5 and later, the sandox creation is optional per https://sinonjs.org/guides/migrating-to-5.0 so it could even simpler:
Based on anecdotal searches in the wild, the above seems to be how most people use Sinon with QUnit.
However, the above would not benefit from Sinon's descriptive error messages. That's why often people avoid Sinon's boolean shortcut methods like
calledWith()
in favour of performing native QUnit assertions on the spy object, like so:But, this isn't a great developer experience and means most documentation and tutorials out there for Sinon won't feel applicable. Instead, we can use Sinon.assert and let it throw descriptive exception messages. This is what https://sinonjs.org/releases/v9.0.3/sandbox/ recommends:
This seems much better for the developer, but it is by default optimises for exception-based test frameworks like Mocha and JUnit, which stop after the first error. QUnit won't see the exceptions as assertion failures so they would technically appear as unexpected exceptions. Which isn't so bad by itself as the UI for that is mostly the same, but it might also trigger "zero assertions" warnings if the test has no other assertions, and that's kind of a deal breaker imho.
Sinon provides an extensible assert API for that reason, so that you can really easily hook it up to QUnit. Per https://sinonjs.org/releases/v9.0.3/assertions/:
The thing is, these are globally static and not part if Sinon's restorable sandbox model. Which means even with before/after hooks, or Sinon's
sandbox.injectInto
feature, it would not be easy to connect it to a local assertion object. (Aside from using globalQUnit.config.current.assert
.)But, there is a dedicated
sinon.assert.expose(obj);
method that does what we need by providing the assertion methods with support for localpass
andfail
callbacks. Below is a hacky way to connect that, as demonstration:This seems to provide the best of both worlds, although the setup is obviously impractical, so we'd want to ship that in a plugin that handles this automatically. There are numerous sinon-qunit plugins out there we could work with, perhaps some of them even do this already?
The text was updated successfully, but these errors were encountered: