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)
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.
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
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
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
Would welcome some thoughts on the module dropdown, how people use it and what you expect its order to be. 👉 qunitjs/qunit#1487
@gibson042 Welcome back :) Recommended reading for catching up, apart form History.md, is mostly js-reporters/js-reporters#133 and qunitjs/qunit#1498. As always, feel free to doubt/ask/question anything!
Just as a personal update, I've recently left MathWorks and started with Google, though I intend to continue contributing here. I had signed the CLA with the okay from MathWorks, and need to re-do that with Google, but it sounds like everything should be smooth beyond those sort of logistics. I won't be submitting any new code until I get that worked out so everyone's safe
I am having a frustrating debate concerning
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?
Is there a value that every test have an expect() or is this just testing that the developer can count?
You have a good instinct :)
If one of those callback functions doesn't run, then the assertions don't run either
It can by solved by following a practice of not putting assertions inside callbacks, or by having an assert.async tracker to ensure it ran.
For existing code bases I wold recommend dropping the lint rule and then gradually phasing it out when you have time to look at a given test. There's certainly no need to mass remove it and might make you miss regressions in older style tests
@Krinkle any advice on how to get that understanding to the folks making the "recommended" rules for eslint? https://github.com/platinumazure/eslint-plugin-qunit/blob/master/docs/rules/require-expect.md
sukima: we are on good terms with them I'd say. platinumazure/eslint-plugin-qunit#69 This provided an easy way to opt out which you could configure from the eslintrc file in your repository as a starting point
I can see why some people might prefer this style, especially if they're used to it. Why make something less strict etc. But yeah maybe they can remove it from the next recommended rule. You can propose it there too if you like, for version 8 platinumazure/eslint-plugin-qunit#222
This new vitest project is concerning me, I'll investigate it better. Compared to qunitx it does multi-threading via tinypool npm package, provides HMR(which I think isnt important), snapshot feature, and coverage for browser run tests(in qunitx its only supported in nodejs mode with c8). Assumption is everyone should use vite and do there tests with vitests but vitest try to offer so much more and jest like API copy & many features/documentations which I feel shouldnt be needed in the first place. This is my criticism of vue & vue related projects in general, they copy whats "popular" but do a bad job at copying. @Krinkle lets have a chat here or on discord if you like I have few ideas & want to discuss with you some limitations I come across with qunitx. Maybe I'll base it on vite instead of an esbuild bundling, there might be few advantages but I'm not sure yet.
@izelnakri Yeah, I see what you mean. Happy to chat here. I'm not on Discord currently. Could also do an impromtu voice chat via Jisti (https://meet.jit.si) at some point if you like, to bounce ideas in real-time.
Few hours in, I'm still trying to figure out if vitest ships with a browser UI. Is this a snakeoil? :D It seems like it hahah They dont seem to provide a visual test filter however I found this to be interesting: https://vitest.dev/guide/features.html#specifying-a-timeout
since vitest watch all files they can adjust global timeout by doing the config in code/api.
So far I see 3 new things I can implement in qunitx: 1- Jest like snapshots. I was planning to create a tap reporter so this reporter can do this: https://jestjs.io/docs/snapshot-testing . 2- Multithreading, I intentionally didnt touch this previously, postponing it until I need it. 3- Extending QUnit.test and QUnit.module() for 3rd optional timeout number argument in code and make QUnit.test.only running only that test.