Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 27 13:25

    github-actions[bot] on gh-pages

    Build commit fc278e8c0d7e90ec42… (compare)

  • Nov 27 13:20

    Krinkle on main

    Docs: Fix a few typos Fixes: … (compare)

  • Nov 27 13:20
    Krinkle closed #1709
  • Nov 26 19:49
    linux-foundation-easycla[bot] commented #1709
  • Nov 26 19:40
    linux-foundation-easycla[bot] commented #1709
  • Nov 26 19:40
    timgates42 opened #1709
  • Nov 10 09:03
    Krinkle commented #1708
  • Nov 10 03:04
    SergeAstapov commented #1708
  • Nov 10 03:03
    SergeAstapov commented #1708
  • Nov 10 03:02
    linux-foundation-easycla[bot] commented #1708
  • Nov 10 02:59
    linux-foundation-easycla[bot] commented #1708
  • Nov 10 02:59
    SergeAstapov synchronize #1708
  • Nov 09 22:14
    linux-foundation-easycla[bot] commented #1708
  • Nov 09 22:14
    SergeAstapov opened #1708
  • Oct 24 00:44

    github-actions[bot] on gh-pages

    Build commit a4354d780f05fee4f9… (compare)

  • Oct 24 00:43

    Krinkle on main

    Docs: Fixed several typos Clos… (compare)

  • Oct 24 00:43
    Krinkle closed #1707
  • Oct 23 09:56
    linux-foundation-easycla[bot] commented #1707
  • Oct 23 09:56
    AndrewDawes reopened #1707
  • Oct 23 09:40
    AndrewDawes closed #1707
Timo Tijhof
@Krinkle
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
Adam Fuhrer
@adamfuhrer
Hey! Having an issue using qunit -w can some help take a look :) qunitjs/qunit#1693
Timo Tijhof
@Krinkle
adamfuhrer: thx, I'm looking into it. Can you confirm that it's okay with you pass a directory argument? Eg qunit-w tests/
I suspect it's the default arg that's lost on reruns. The rest we have covered with tests.
Adam Fuhrer
@adamfuhrer
thanks for the quick response
running into the same issue unfortunately :(
I'll add the screenshot to the issue
Timo Tijhof
@Krinkle
adamfuhrer: thx, I've done a basic attempt at reproducing it in a clean directory but it appears to not happen for me. Do you use any plugins or QUnit.config overrides?
Adam Fuhrer
@adamfuhrer
appreciate it! followed up in the github issue. maybe I'll play around with a different node version. good to know it's not a more widespread issue
Stephen Griffin
@stephenegriffin
I installed (and am already using quint from html) but am a bit lost trying to access the CLI. Basically hitting this: https://stackoverflow.com/questions/41802224/qunit-is-not-recognised-as-an-internal-or-external-command-operable-program-o. Is there some other pre-req to getting a qunit command available on cli?
Timo Tijhof
@Krinkle
@stephenegriffin Refer to the example at https://qunitjs.com/intro/#in-nodejs. if you run qunit directly, or from npm test, it will by default run test/**.js files in which you place QUnit.test() blocks to define your test cases.
@stephenegriffin I'm afraid the stackoverflow answer is incorrect and a bit outdated as well. We've actually had a built-in CLI for many years now!
Alternatively, if what you want is to run tests from the CLI, but don't mind if it's in a browser (e.g. your program is not actually a Node program, but you're using Node as a way to test on the CLI) then you can also consider karma-runner which lets you run QUnit tests in Headless Firefox/Chrome direclty from the CLI. The above examle-node-and-browser is for projects where your program is meant to support both node and browser. If you only need to support the browser, then you can use karma to run it in a browser from the CLI. Example: https://github.com/qunitjs/qunit/tree/main/test/integration/karma-qunit
Stephen Griffin
@stephenegriffin
@Krinkle I got qunit to run from inside npm test, but when I run qunit directly from the command line (windows, so cmd.exe) there's no qunit.exe or qunit.cmd on the path. Tried the same on linux using bash and still no qunit on the path.
Timo Tijhof
@Krinkle
@stephenegriffin Correct. This is expected when working with node and npm programs. The convention in the industry is to not install programs relating to the development of a project globally, but keep it local to your project directory and run via npm run .. or npm test. To instal it globally in your path would mean that your computer in general has 1 central version of QUnit. This is useful for generic utilities like 'npm' itself, but
less so for development tools where different projects might need different versions. Via npm these can be controlled in package.json.
Stephen Griffin
@stephenegriffin
Is this a node/npm thing? I see so much documentation on npm packages, like this one, that show the command being run directly on a cli but I can only get them to work by building out a script in package.json. They just don't exist from command line and I don't know why.
Timo Tijhof
@Krinkle
@stephenegriffin Yes, it's a node/npm thing. Though also common in other ecosystems either, such as PHP composer/packagist. I agree this is confusing when trying it out the first time. It is assumed that you know that commands will only be run from inside package.json under scripts.<something> where the command is available (the sub-shell that npm uses has $PWD/node_modules/.bin/ in its path), or that if you are debugging it to run directly, that you know to prefix it with ./node_modules/.bin/<command> or npx <command> or npm run <script> -- <args>
Stephen Griffin
@stephenegriffin
Thanks for your help. I currently have qunit running in a test.html type page I can load after building, which works fine, but would be better if I could run those tests through npm test. Complication is I'm testing typescript built through webpack and I cannot find any examples that do this.
Timo Tijhof
@Krinkle
@stephenegriffin can you confirm if your project is itself meant to be used by other people as a Node package, or only in the browser?
Stephen Griffin
@stephenegriffin
Project is just a web page.
Timo Tijhof
@Krinkle

Okay, in that case the two main options I can recommend are:

  1. karma. This would mean you set files: in the karma config to the same list of scripts that your test HTML file currently loads, e.g. the source TS files and unit test files. You can use wildcards for simplicity. You will then need to enable a preprocessor in Karma for TypeScript. This is suppoted by Karma. I suspect you can skip the Webpack step, but it depends on whether you use it for any special features or not. This isn't specific to QUnit, but happy to help.

  2. Alternatively, you can ues grunt-contrib-qunit. This has the benefit of letting you re-use the existing unit test HTML page and existing webpack config. The downside is that you will then need to run webpack before starting the tests. For example "test": "npm run build:dev && grunt qunit".

Stephen Griffin
@stephenegriffin
Thanks again. Since the goal is to test the webpack output anyway grunt should work just fine. I keep getting "Failed to load resource: net::ERR_FILE_NOT_FOUND" when I run it though and don't know what my troubleshooting options are. I also think I didn't config everything I was supposed to... not working attempt
Timo Tijhof
@Krinkle
@stephenegriffin The current Gruntfile there refers to Pages/unittest.html as a file (not a URL). From what I can see, there is no such file in the repository at that location. There is src/Pages/unittests.html but this contains no JS. I'm guessing this is a template file that you serve through another web server? If so, specify the URL to that web server in Gruntfile.
Stephen Griffin
@stephenegriffin
it's a file built through npm run build
Timo Tijhof
@Krinkle
@stephenegriffin if you drag that file into a web browser directly (which should get a URL like file:\\C:\myproject...) does that work? grunt-contrib-qunit essentially opens the file in a similar way when it is not a URL.
Stephen Griffin
@stephenegriffin
good call - that was working but I must have broken it - live debug errors match what I see from grunt so fixing one should fix the other. Thanks again for all your help.
Timo Tijhof
@Krinkle
Glad that worked :) Feel free to ask again if you get stuck!
Stephen Griffin
@stephenegriffin
Got it all working - have a few tests to fix before I can commit and merge but I've got something I can play with now.
Pavel
@MozgC

Hello guys,
This is my first-ever javascript/html test.
I need to test my function on multiple html inputs.
For example see:
https://github.com/MozgC/chess.com/blob/main/QUnit/test.html &
https://github.com/MozgC/chess.com/blob/main/QUnit/test3.html

As you can see, there's a lot of code duplication at the beginning of html files.
How can avoid this duplication? <--- MAIN QUESTION

Let's say I need to test my getPgn() function on 10 different htmls and get 10 different returned values.
You can see I tried to load html for a 2nd test here:
https://github.com/MozgC/chess.com/blob/main/QUnit/test.html#L22
But it doesn't work

Timo Tijhof
@Krinkle

@MozgC When loading content from a separate file, this is usually asynchronous in JavaScript. That means it is kind of like it happens in the background while the code moves on. This is not specific to QUnit, but I can point you in the right direction.

For example, if you use the following, I imagine it works as expected:

QUnit.test('bla2', function(assert) {
    $("#mainDiv").html(`<vertical-move-list board-id="board-vs-personalities">...</vertical-move-list>`);
    var res2 = getPgn();
});
Timo Tijhof
@Krinkle

Usually in JavaScript we use a Promise here and then await it from an async function. QUnit supports this as well, to make it easy to run an asynchronous preparation step like this, and then continue with the test after that is done.

For example:

QUnit.test('bla2', async function(assert) {
    var loading = new Promise(function (resolve) {
        $("#mainDiv").load("./test2.html", resolve);
    } );
    await loading;

    var res2 = getPgn();
});

Or, another way that may be simpler by using $.ajax directly instead of jQuery load():

QUnit.test('bla2', async function(assert) {
    var myHtml = await jQuery.ajax( {
            url: "./fixture2.html",
            dataType: "html"
    });
    $("#mainDiv").html(myHtml);

    var res2 = getPgn();
});

More examples at https://api.qunitjs.com/QUnit/test/

Pavel
@MozgC
@Krinkle Thank you so much!
One problem was async execution, another problem was that the Chrome browser I used to debug was not allowing loading local files.
@Krinkle Can you please take a look at my latest code: https://github.com/MozgC/chess.com/blob/main/QUnit/test.html
Looks good? Any further improvement suggestions?
Pavel
@MozgC
Probably using object data provider instead of writing multiple asserts would be the next step.
Timo Tijhof
@Krinkle

@MozgC Yeah, data providers could shorten this code a bit further.

If you like arrow function syntax, one could shorten loadHtmlFile a bit further as well, e.g. await new Promise(resolve => $(where).load(filename, resolve));

If you want to automate the testing during development (e.g. via npm test in VSCode, or manually on Windows with PowerShell, Git Bash, or WSL) or possibly to integrate with Jenkins CI or GitHub Actions, then you can checkout https://qunitjs.com/intro/#integrations. For example, you could use Node.js with npm and grunt-contrib-qunit and then have it so that npm test will run the test and print the results. If needed, you can keep setting --allow-file-access-from-files as now via Gruntfile.js.

But... that's a fair bit of extra work. That can be useful if you make a lot of changes or need to review changes by other people. Up to you! Testing manually as you do now certainly work as well. All the Node.js and npm stuff is optional with QUnit.

Pavel
@MozgC
@Krinkle Thanks very much!
Even if nobody else will work on this project, I'd still want to learn best practices (I mostly work on backend, so not very good at javascript & its best practices), so thanks!