[RFC] Add test runners to project during quasar init

[nothingismagick]

This RFC is about enabling the installation and integration of unit test-runners, e2e frameworks and quality control into the Quasar Framework. It is not a discussion about "if we should do this", but rather a discussion about the approach. After meeting with several contributors helping to scaffold the testing mode, our current opinion about how the flow should work is as follows:

0. The user calls quasar init mypackage
1. The user is asked if they want to include one of each of test types a. UNIT TEST (ava, jasmine, jest, mocha, tap) includes istanbul/nyc, chai, sinon b. E2E TEST (cypress, karma, nightwatch) c. QUALITY (lighthouse)
2. These decisions are passed back to quasar-cli
3. quasar-cli adds the mypackage/test folder, installs the base @quasar-test/base repo
4. Each of the above test runners is a folder within the namespaced monorepo which are also installed (such as @quasar-test/ava, @quasar-test/cypress, @quasar-test/lighthouse)
5. As a post-install step, test-runner configs, src and output folders are copied or created in the mypackage/test folder.
6. Where necessary, the mypackage/package.json is updated with configs for the test runners.
7. Test commands are created in the mypackage/package.json, so that the user can run tests with yarn/npm.
8. Where necessary, webpack-chain commands and aliases are added to mypackage/quasar.conf.js
9. mypackage/.babelrc is updated accordingly
10. Upon conclusion, the "test mode" is set and visible when the user runs quasar mode:

    

The monorepo is under construction here:

https://github.com/quasarframework/quasar-test

Test runners currently verified to have valid "integration" at the moment are checked off in the following list:

UNIT

• [x] @vue/test-utils
• [x] ava
• [x] chai
• [x] jest23
• [x] mocha
• [ ] mocha-loader (for webpack)
• [ ] mocha-webpack
• [ ] jasmine
• [x] sinon
• [ ] tap
• [ ] tape

E2E

• [ ] appium (cordova)
• [x] cypress
• [ ] karma
• [ ] nightwatch
• [ ] spectron (electron)

QUALITY

• [x] lighthouse 3.0
• [ ] import-cost
• [ ] bundlesize

List of known javascript unit-testing frameworks this comment will be updated as more land

Matching Quasar Cli RFC regarding quasar test quasarframework/quasar-cli/issues/127

[Arushi-Jain]

In order to download testing dependencies along with the quasar template, I forked the quasar-starter-kit and changed the package.json. It downloads only the dependencies for unit test for now only when the user says yes to the question asked (edit meta.js to change the questions asked). Quasar-cli is needed only to create the folder for those tests, for now I create the folder myself for unit testing while the dependencies are downloaded only i choose to.

[nothingismagick]

Regarding your comment in general, we have moved to babel7 and webpack4 - your package.json shows that your source is not up to date with quasar 0.16.1...

[Arushi-Jain]

But this approach will even work, we are just creating our own template using quasar-starter-kit . with quasar 0.16.1 we may have to change the version of the webpack loaders in webpack.test.config.js

[nothingismagick]

Yes, your approach would theoretically work, but the thing is that we want to centrally manage the packages installed for the various test runners. We are not merely offering mocha-webpack. Further, this approach does not hook into the webpack chain of quasar 16+ - which in my opinion is the only reason to use mocha webpack. Otherwise just use jest or Ava...

[nothingismagick]

For your information, I was also able to integrate mocha-webpack into quasar 15, it is Babel and the new webpack approach that makes it challenging with 16.

[Arushi-Jain]

Thank you for your insights, I will definitely look into it.

[alansoliditydev]

why use mocha instead of jest?

Jest is very strong supported by facebook, we will need jest snapshot & image snapshot to get pixel perfect test for UI.