Without run qunit tests into a directory, do you know if it is possible to have/get a static report/numbers about total tests into the directory?
Like total number of tests show into the top of the web page ".../tests?hidepassed" ?
Thank you
Like total number of tests show into the top of the web page ".../tests?hidepassed" ?
Thank you
Hi QUnit users.
I use QUnit in a project to take screenshot using pupeteer then compare it.
But I want run this test on a list of files. So I need to create QUnit test in an forEach loop in some asynchronous tasks.
Each time I try, QUnit return a first global error
What i'm doing wrong ?
I use QUnit in a project to take screenshot using pupeteer then compare it.
But I want run this test on a list of files. So I need to create QUnit test in an forEach loop in some asynchronous tasks.
Each time I try, QUnit return a first global error
Error: No tests were run.What i'm doing wrong ?
I've got a Gitter channel for eslint-plugin-qunit, if we want to discuss anything further there: https://gitter.im/platinumazure/eslint-plugin-qunit
Hey folks. I'm reviewing platinumazure/eslint-plugin-qunit#94 and I wanted to check: Did QUnit ever support
hooks.setup and hooks.teardown, or were those only on module calls with an object argument rather than the callback function?
platinumazure: Good question! Support for setup/teardown was removed in 2.0 and much of the multi hooks and nesting was built out within 2.x. But... nested hooks itself did land in 1.x and it did live side-by-side with setup/teardown. But... it was added after we started deprecating setup/teardown, and we only supported those as module options.
This snapshot shows setup/teardown coming in from test env, and moduleFns (module hooks object) supporting the newer beforeEach/afterEach methods.
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.
and in my code I do see references to "qunitjs"
the nodejs CLI command is part of the same package before/after the rename and similarly compatible. Only the npm package name was renamed.
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)
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.
I would recommend giving it a try and see how it goes! For most projects, no other changes are needed :)
I am gonna give it a try
: )
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
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.
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
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.
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.
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 :-)
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...
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
@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.
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)