Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 15 01:15

    Krinkle on docs

    Docs: Avoid new syntax in class… (compare)

  • May 15 01:03

    Krinkle on docs

    Docs: Avoid new syntax in class… Docs: Clarify how to optionally… (compare)

  • May 11 17:49
    Krinkle commented #1391
  • May 11 17:49
    Krinkle commented #1391
  • May 09 23:15

    github-actions[bot] on gh-pages

    Build commit 96b9275fbd3972b859… (compare)

  • May 09 23:13

    Krinkle on test-integration-onerror

    (compare)

  • May 09 23:13

    Krinkle on main

    test: Add uncaught-error case t… (compare)

  • May 09 09:09
    Krinkle edited #1685
  • May 09 00:34

    Krinkle on test-integration-onerror

    test: Add uncaught-error case t… (compare)

  • May 02 16:27

    github-actions[bot] on gh-pages

    Build commit 87c6f0bf7baa68b40a… (compare)

  • May 02 16:27

    Krinkle on release

    (compare)

  • May 02 16:27

    Krinkle on main

    Build: Prepare 2.19.1 release (compare)

  • May 02 16:24

    Krinkle on 2.19.1

    Release 2.19.1 (compare)

  • May 02 16:21

    Krinkle on release

    Build: Prepare 2.19.1 release (compare)

  • May 02 16:15

    github-actions[bot] on gh-pages

    Build commit 4ecbb349e4e50fd5e1… (compare)

  • May 02 16:15

    Krinkle on ci-node-16

    (compare)

  • May 02 16:15

    Krinkle on main

    Build: Add Node 16 to CI matrix (compare)

  • May 02 16:08

    Krinkle on ci-node-16

    Build: Add Node 16 to CI matrix (compare)

  • May 02 16:07

    Krinkle on ci-node-16

    Build: Add Node 16 to CI matrix (compare)

  • May 02 12:28
    Krinkle closed #180
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 ♥️
Timo Tijhof
@Krinkle
@smcclure15 Let me know if you get stuck on the gem/bundler setup.
Timo Tijhof
@Krinkle
@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!
Steve McClure
@smcclure15
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
Timo Tijhof
@Krinkle
Thanks. We're also doing some CLA/DCO switcheroo at the moment. So thing s might change in the next 2-3 weeks.
Devin Weaver
@sukima
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?
Timo Tijhof
@Krinkle
sukima: I would consider use of expect() an outdated practice, so long as a few guidelines are followed
You have a good instinct :)
Timo Tijhof
@Krinkle
The idea with expect() was to avoid a test case ending without an error but before all things were done. In particular asynchronous tests. It's very easy to write a test such that it will pass when everything is okay but also passes when it's not okay.
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
Devin Weaver
@sukima
Thank you.
@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
Timo Tijhof
@Krinkle
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
Devin Weaver
@sukima
Thanks
Izel Nakri
@izelnakri
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.
Timo Tijhof
@Krinkle
@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.
Izel Nakri
@izelnakri
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.
Izel Nakri
@izelnakri
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.
Izel Nakri
@izelnakri
I thought they'd provide a browser UI like qunit or cypress, seems like it doesn't exist? What a disappointment, another hyped tool