Krinkle on docs
Docs: Avoid new syntax in class… (compare)
Krinkle on docs
Docs: Avoid new syntax in class… Docs: Clarify how to optionally… (compare)
github-actions[bot] on gh-pages
Build commit 96b9275fbd3972b859… (compare)
Krinkle on test-integration-onerror
Krinkle on main
test: Add uncaught-error case t… (compare)
Krinkle on test-integration-onerror
test: Add uncaught-error case t… (compare)
github-actions[bot] on gh-pages
Build commit 87c6f0bf7baa68b40a… (compare)
Krinkle on release
Krinkle on main
Build: Prepare 2.19.1 release (compare)
Krinkle on 2.19.1
Release 2.19.1 (compare)
Krinkle on release
Build: Prepare 2.19.1 release (compare)
github-actions[bot] on gh-pages
Build commit 4ecbb349e4e50fd5e1… (compare)
Krinkle on ci-node-16
Krinkle on main
Build: Add Node 16 to CI matrix (compare)
Krinkle on ci-node-16
Build: Add Node 16 to CI matrix (compare)
Krinkle on ci-node-16
Build: Add Node 16 to CI matrix (compare)
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
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...
npm test
idiom and get it the same way as otherwise.
require("qunit")
and run that, which is missing a lot of protections and debug utilities. I wouldn't recommend it personally
qunit ./test/*.js
or simply qunit
from the test command.
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.
if this.foo
and tear down that one of it was assigned during the test.
assert.async
vs. assert.expect
In cases where I am using assert.async
they are saying expect is required (per lint rules) and I do not understand the value of repeating myself and counting assertions when the tests will fail if the callback are not ran. What is the benefit to having expect when the callback is using the async() don function?