qunitjs/qunit

An easy-to-use JavaScript Unit Testing framework. https://qunitjs.com

Timo Tijhof

@Krinkle

https://github.com/qunitjs/qunit/blame/813849cf2cceb72cc39bcfc98f74370bd07c7248/src/core.js#L22

This snapshot shows setup/teardown coming in from test env, and moduleFns (module hooks object) supporting the newer beforeEach/afterEach methods.

Kevin Partington

@platinumazure

Got it, so hooks.setup() and hooks.teardown() were never valid as far as I can understand. Let me know if I am missing anything. Thanks!

Timo Tijhof

@Krinkle

That's right. They never existed.

Timo Tijhof

@Krinkle

Any Sinon users in the room? I'd like to know your preferred way of integrating with QUnit. See issue qunitjs/qunitjs.com#161 for where I'm collecting ideas for a recommendation to document on the site.

jamesz17

@jamesz17

Hi, I am using qunitjs (version 2.4.1), and I saw a message that "qunitjs" is deprecated and replaced by "qunit". Is "qunit" a drop in replacement for "qunitjs", i.e. no changes needed? We do use qunit for our unit tests.

and in my code I do see references to "qunitjs"

Timo Tijhof

@Krinkle

@jamesz17 That's right. If your JS test suite HTML entry point is loading qunitjs 2.x from node_modules via npm, then you can smoothly update to "qunit" 2.x where the same codebase continued. drop-in replacement :)

the nodejs CLI command is part of the same package before/after the rename and similarly compatible. Only the npm package name was renamed.

jamesz17

@jamesz17

@Krinkle thanks for the quick reply. Do I need to change the references in my code from "qunitjs" to "qunit" if I update to "qunit" 2.x ?

I assume I can directly remove "qunitjs" from npm package.json and add "qunit" 2.x without changing anything else? (there is no breaking changes if I do that)

Timo Tijhof

@Krinkle

@jamesz17 The only change is the package name. Depending on how your tests are run, you may have strings that include the package name. For example, require("qunitjs") would become require("qunit")

If you use git, then git grep qunitjs should find any places that might need an update.

For most projects, no changes are needed. The API is on the QUnit object, which has not changed. and the CLI command is still called qunit, same as before.

jamesz17

@jamesz17

@Krinkle I am not sure what do you mean by "JS test suite HTML entry point is loading qunitjs 2.x from node_modules via npm"? do you mean installing qunitjs via npm?

Timo Tijhof

@Krinkle

@jamesz17 Yes, for example, if you install qunitjs from npm and load it in test/index.html as <script src="node_modules/qunitjs/qunit.js"> then you only need to edit package.json and then update the directory name in that <script> path.

I would recommend giving it a try and see how it goes! For most projects, no other changes are needed :)

jamesz17

@jamesz17

@Krinkle thank you

I am gonna give it a try

: )

Steve McClure

@smcclure15

hi gang - i guess im the new guy. thank you @Krinkle for the invite to this group!
i work on Test Infrastructure at MathWorks and we have oodles of QUnit tests running continuously, so i certainly have a vested interest, but this engagement is fun regardless :-)

and now down to business... do you think we should drop Phantom support with 3.0? there's still some pieces inside the reporter/html.js logic. I came across it because im looking at code coverage with a fine-toothed comb, looking to boost coverage of any low-hanging fruit

Timo Tijhof

@Krinkle

@smcclure15 Hey, welcome!

Good question. I think as a web developer I mostly tend to no longer support PhantomJS. However for QUnit specifically I think there might still be lots of users using PhantomJS without realizing it, e.g. as part of a wrapper that happens to use it internally. But.. I think all of the wrappers and runners I am aware of, have since adopted Headless Firefox, or Headless Chrome, or indirectly via puppeteer.

So.. yeah, I think we can drop it for QUnit 3.0. Would be good to provide a deprecation warning for that before then.

Steve McClure

@smcclure15

that makes sense, thanks.
i started implementing that, then realized that this is probably true of other browsers too. should we have a utility (maybe something near globals.js) to warn about certain deprecated browsers? we have a lot of scaffolding and fallthroughs for the older envs, so we could warn when we know we've had to gracefully degrade/polyfill.

i guess my point is, i assume we'd want to warn for each browser we want to drop in 3.0, but not produce too much noise for warning at every turn. if that outlook is agreeable, i can work on that and propose a PR

Timo Tijhof

@Krinkle

We haven't used warnings in jquery or qunit in the past for general browser support. It's an interesting idea though. I think PhantomJS could use special treatment as its often used without developers thinking about it as a browser. That is, if we were to announce that QUnit requires IE11+, Firefox N+ and drops PhantomJS support, I worry developers might look at their test matrix and shrug, not realizing that while their code doesn't need to work in PhantomJS, that their unit test runner might be be depending on that indirectly. Similar to e.g. if (unlikely) we were to find a bug specific to Puppeteer or something like that.

Timo Tijhof

@Krinkle

fyi, I just re-authenticated Coveralls. It somehow lost the GitHub permission to display source code from the repo, which meant it said "Source Not Available" at https://coveralls.io/builds/34875937/source?filename=src/core.js. This is now fixed.

Steve McClure

@smcclure15

that sounds fair about the browser support - PhantomJS could surprise some folks, and I can issue a warning for that. I'll leave the broader "this browser will be deprecated" can-of-worms alone....

and thanks for touching up the coveralls. I loooooove a green coverage report :-)

Steve McClure

@smcclure15

does anyone have a go-to grunt task to run QUnit node tests?

i've found grunt-qunit-node, grunt-node-qunit (both very old), grunt-contrib-qunit (but that's just for HTML browser tests), and then there's https://github.com/qunitjs/node-qunit, which looks maintained, though still uses some 1.x globals in the readme, and I wasn't sure how easy it was to pull that into Grunt ecosystems...

Timo Tijhof

@Krinkle

@smcclure15 I typically run it outside grunt, by adding && to the test command in package.json. E.g. "test": "grunt && qunit"

Then the user can run the standard npm test idiom and get it the same way as otherwise.

Having said that, we technically have a grunt task for running qunit on node inside our repository: https://github.com/qunitjs/qunit/blob/2.12.0/build/tasks/test-on-node.js - This, however, is not comparable to the QUnit CLI, rather it is comparable to the less common approach of manually running a node script in which you require("qunit") and run that, which is missing a lot of protections and debug utilities. I wouldn't recommend it personally

Steve McClure

@smcclure15

thanks @Krinkle for that context. I ended up simply using js-reporters with TAP output and requiring my test files. very flexible and elegant!

Timo Tijhof

@Krinkle

@smcclure15 awesome. So if I understand correctly - this involves a Node.js script where you require qunit + test suites and attach the TAP reporter. That's good, but I just wanted to double check that you want/need that vs using the CLI. Is this preferred in general or did you run into an issue? If so, I'd love to know what that is (if you can share) as it could help us to improve the CLI (https://qunitjs.com/cli/) . Ideally all you'd need to do is qunit ./test/*.js or simply qunit from the test command.

Steve McClure

@smcclure15

Yea i want to revisit using the CLI directly for a lot of the freebie logic. Adding it to the package.json scripts was awesome in my local dev, but it seemed like our CI system required it to be a grunt task for proper triggers/reporting/checks. I'll try to revisit that this week (in addition to catching up on some QUnit github traffic (2.13!? sweet :-)) I saw while I was AFK the past holiday week)

Steve McClure

@smcclure15

btw, i plan to circle back on the QUnit.load deprecation plan. hopefully it's close

Timo Tijhof

@Krinkle

RFC: Transitioning js-reporters to fully embrace TAP. – js-reporters/js-reporters#133

Timo Tijhof

@Krinkle

I've renamed the head branch to main for qunitjs/qunit. Update your local copies with git remote update && git checkout -B main -t origin/main.

xmo-odoo

@xmo-odoo

Hello, sorry to bother but I wanted to know if there's a "cleanup" concept in qunit. A form of afterEach but only for the current test if you want.

I looked at the assert object but nothing related to that seems documented.

Defining a global afterEach with a queue of callbacks would be an option I guess, but I wanted to know if something already existed for that.

Timo Tijhof

@Krinkle

Hi xmo-odoo, if you need a callback with complex local code for one test, then something like that would work well indeed. The afterEach could be attached to a scoped module and check a list of callback attached to "this".

Another way would be to place the logic in the afterEach itself, and make it conditional. That's the way I usually follow.

For example, if some tests create a Foo object and some Bar, and some both. Then your afterEach can check if this.foo and tear down that one of it was assigned during the test.

Lastly, if you haven't tried nested modules before, that might also be an option: https://api.qunitjs.com/QUnit/module/#example-hooks-on-nested-modules

Timo Tijhof

@Krinkle

That would allow you both: multiple callbacks some default, some specific to a subset of tests!

Steve McClure

@smcclure15

that's actually something that's on my "rainy day" list of things to hack at, something like MATLAB Unit's "addTeardown" method:
https://www.mathworks.com/help/matlab/ref/matlab.unittest.testcase.addteardown.html
One of the wins is fewer variables, like if you have a before hook setting something, instead of restoring state in the after hook, you just say "addTeardown" and do it in there, and the lifecycles are handled. not sure of the feasibility, but wanted to throw it out there

zsinba

@zsinba

thanks

Timo Tijhof

@Krinkle

Would welcome some thoughts on the module dropdown, how people use it and what you expect its order to be. 👉 qunitjs/qunit#1487

Steve McClure

@smcclure15

Kudos to the gang on release 2.16.0! I feel like that had a lot of collaboration among different parties that was very enjoyable to be a part of. It's great to be able to work with all of you and deliver some cool stuff together

Timo Tijhof

@Krinkle

+1 ♥️

Where communities thrive

People

Repo info

Activity