-
-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update QUnit to latest #653
Comments
I would like to work on this |
OK, thanks @rohitgeddam . |
I would like to work on this |
@SakshiSarna OK! |
I would like to work on this , but currently the latest version is 2.11.3 |
Yes you're right @ram690514 . I don't know where I got that other number from. I see the previous person who offered has deleted their account, so I'll assign you. |
thankyou @Jaifroid |
i have created a pull request but it is showing some errors can you help me @Jaifroid |
@ram690514 Because you do not have write access to this repo, the tests won't run properly and will appear to fail. |
@Jaifroid , i reopened it |
@Jaifroid : I don't know but the latest version of Qunit is not working with this project , maybe it is because of my fault . can you please help me to fix this issue |
@ram690514 It would be helpful to know what you've tried. What errors are showing in dev console? You need a bit more informaiton than "it is not working" so that I can meaningfully help you! |
I changed Qunit 2.3.2.js to Qunit2.11.3.js and also CSS file get replaced .
but now when i load the test.html file it get show " 0 out of 4 files
checked ".
actually I updated by using npm command " npm install Qunit". I think may
be there exist some other ways to update the existing Qunit file , may be
you can help me.
But at the same time i also found that there is no package.json file in
this project .
can you please explain a step by step method to fix this issue...please.
…On Tue, Oct 20, 2020 at 9:06 PM Jaifroid ***@***.***> wrote:
@ram690514 <https://github.com/ram690514> It would be helpful to know
what you've tried. What errors are showing in dev console? You need a bit
more informaiton than "it is not working" so that I can meaningfully help
you!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#653 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARAWVBVCD2P3HCCNJMCUFVTSLWU6JANCNFSM4R5OHJZQ>
.
|
@ram690514 This is not an npm-enabled project. We have #554 for that issue. For now you have to update dependencies manually. If I were you I'd start again with master: make sure you know how to run the tests under the master branch and make sure they work. Then manually update just the QUnit files (by downloading and dropping in). You may need to look carefully at what has changed in the QUnit API, to be sure that the way in which tests.html and associated files are evoking it is still the correct one. I can't provide you with a step-by-step method, because then I'd be fixing this issue myself! Youi have to go through patiently, one step at a time, and debug at each step. And don't use npm with this project, as it won't work. |
You were on the right track with #660 : it was the right way to upgrade QUnit, but some APIs have probably changed. Run tests.html to see what's wrong |
I'd be happy to help update QUnit and address (some of) #554. I don't want to stand in the way if someone else is already working on this, however. Let me know! Strawman proposal (feel free to suggest otherwise):
It should also be fairly straight-forward after this to plug in karma-coverage to produce a test coverage report (example 1, example 2) - ref #528. |
PS I have no experience of Karma Runner, maybe @mossroy should comment on that part. |
@Krinkle : this contribution would be very welcome, and goes way further than this issue. Let me give some more general background : I've heard and used a bit Karma, but I don't have much experience on frontend testing frameworks. So I can't say which ones best suits our needs. As you seem to have this experience, if you think it's a good choice, I'm following you. NB : until #590 is done, the PRs made from forks of this repo can not run the CI. So, if you work on enhancing the CI, we'll need to give you more rights (probably add you as a member of kiwix team on github). @kelson42 : are you ok with that? |
* Load qunit package from npm. Start of a larger transition, ref kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to run a QUnit web page with Nightwatch, this was not ideal. This had numerous limitations, such as: - relies on fragile an unsupported web scraping to collect results, which can easily break between versions. ref kiwix#660. - results provide limited debugging information when a test fails. - cannot easily be run locally from the command-line since the Nightwatch config is currently written for SauceLabs, and creating a local configuration is not easy because Nightwatch has a hard requirement on webdriver (which makes sense for UI tests), which people usually do not have installed or may be incompatible with the current version of their browser. These then also have to be configured and started etc. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. * Using Karma means: - You can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact runner is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests from within there without exposing anything from your personal computer, except the current working directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, and then submit this to Codecov or Coveralls, ref kiwix#528. * I have restructured the Travis CI file so that the cross-browser test in SauceLabs are skipped for PRs from forks. Instead, those PRs will run the unit tests in local Fireox and Chrome within Travis CI. This avoids the confusing failures and still gives (some) useful results. The tests that Travis CI runs are the same as what users can run locally if they invoke `npm test` (after a one-time run of `npm install` to fetch dependencies into the local node_modules directory). This restructuring uses the 'stages' feature which is not compatible with the 'deploy' feature. I had converted the two deploy stages to use the 'stages' feature as well so that these continue to work. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently switch major versions that may contain breaking changes. Fixes kiwix#653.
* Load qunit package from npm. Start of a larger transition, ref kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to run a QUnit web page with Nightwatch, this was not ideal. This had numerous limitations, such as: - relies on fragile an unsupported web scraping to collect results, which can easily break between versions. ref kiwix#660. - results provide limited debugging information when a test fails. - cannot easily be run locally from the command-line since the Nightwatch config is currently written for SauceLabs, and creating a local configuration is not easy because Nightwatch has a hard requirement on webdriver (which makes sense for UI tests), which people usually do not have installed or may be incompatible with the current version of their browser. These then also have to be configured and started etc. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. * Using Karma means: - You can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact runner is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests from within there without exposing anything from your personal computer, except the current working directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, and then submit this to Codecov or Coveralls, ref kiwix#528. * I have restructured the Travis CI file so that the cross-browser test in SauceLabs are skipped for PRs from forks. Instead, those PRs will run the unit tests in local Fireox and Chrome within Travis CI. This avoids the confusing failures and still gives (some) useful results. The tests that Travis CI runs are the same as what users can run locally if they invoke `npm test` (after a one-time run of `npm install` to fetch dependencies into the local node_modules directory). This restructuring uses the 'stages' feature which is not compatible with the 'deploy' feature. I had converted the two deploy stages to use the 'stages' feature as well so that these continue to work. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently switch major versions that may contain breaking changes. Fixes kiwix#653.
* Load qunit package from npm. Start of a larger transition, ref #554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to run a QUnit web page with Nightwatch, this was not ideal. This had numerous limitations, such as: - relies on fragile an unsupported web scraping to collect results, which can easily break between versions. ref #660. - results provide limited debugging information when a test fails. - cannot easily be run locally from the command-line since the Nightwatch config is currently written for SauceLabs, and creating a local configuration is not easy because Nightwatch has a hard requirement on webdriver (which makes sense for UI tests), which people usually do not have installed or may be incompatible with the current version of their browser. These then also have to be configured and started etc. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. * Using Karma means: - You can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact runner is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests from within there without exposing anything from your personal computer, except the current working directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, and then submit this to Codecov or Coveralls, ref #528. * I have restructured the Travis CI file so that the cross-browser test in SauceLabs are skipped for PRs from forks. Instead, those PRs will run the unit tests in local Fireox and Chrome within Travis CI. This avoids the confusing failures and still gives (some) useful results. The tests that Travis CI runs are the same as what users can run locally if they invoke `npm test` (after a one-time run of `npm install` to fetch dependencies into the local node_modules directory). This restructuring uses the 'stages' feature which is not compatible with the 'deploy' feature. I had converted the two deploy stages to use the 'stages' feature as well so that these continue to work. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently switch major versions that may contain breaking changes. Fixes #653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.12. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.13. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.13. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.13. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.13. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* Load qunit package from npm, this is the start of a larger transition. ref at kiwix#554. * Update QUnit from 2.3 to 2.13. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on the fragile and unsupported DOM scraping to collect results, which breaks between versions. ref kiwix#660. - severely limits debugging information for failing tests. - cannot easily be run or debugged locally from the command-line since as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server first. People usually do not have this installed and is hard to set up. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref kiwix#528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes kiwix#653.
* workflows: Rename "CI" to "Release" Rename this to make space for a separate "CI" workflow that will run continuous integration and testing jobs for commits and PRs. * workflows: add CI workflow for unit tests and support running locally * Load qunit package from npm, this is the start of a larger transition. ref at #554. * Update QUnit from 2.3 to 2.13. * Use Karma for the running of unit tests (instead of Nightwatch). While it was possible to use a fake "UI" test to open the QUnit web page with Nightwatch, this had numerous limitations: - relies on fragile and unsupported DOM scraping to collect test results, which breaks between framework versions. ref #660. - severely limits debugging information for failing tests. - cannot easily be reproduced or debugged locally from the command-line as the Nightwatch config was pinned to Sauce Labs, and creating a local configuration is not easy because Nightwatch has a hard requirement for installing and running a WebDriver server. People usually do not have this installed and it's non-trivial to set up and keep working in the long term, and across multiple different software projects. - cannot easily be run in a secure container separate from your personal computer, thus putting personal data at risk. - lacks wider integration and plugins to enrich unit testing, such as test coverage reports. Using Karma means: - We can run 'npm test' locally during development and have it automatically run the tests in headless Firefox and Chrome and report back, all from the command-line. - The same exact same stack is also used in CI with SauceLabs for additional browser coverage (same as before). - It has no external dependencies other than the plain web browser itself. This means if you have a development container (e.g. based on Docker) that has Node.js + Firefox + Chromium, you can run the tests there without exposing anything from your personal computer, besides the current directory. <https://timotijhof.net/posts/2019/protect-yourself-from-npm/> - In a future change, we can plug in karma-coverage to generate a test coverage report, to submit to Codecov or Coveralls. ref #528. * I have pinned the version of 'http-server' and 'nightwatch' in package.json so that these don't silently upgrade in a way that may introduce security issues or drop compatibility for the environment we currently support. Fixes #653. * Re-enable unit and UI tests in latest Edge The tests were disabled after #499 due to an issue with the Edge version that was the default "edge" on SauceLabs in May 2019 (not sure which version that was, the last pre-Chromium Edge version was 44, which was passing, so perhaps SauceLabs defaulted to a beta release, or used a much older version like 15-18?) Now that Edge uses Chromium, try re-enabling the tests. Fixes #502.
Latest QUnit is 2.22.2 from 09/09/2020.
(Maintaining dependencies would be much easier if we could start #554...)
The text was updated successfully, but these errors were encountered: