Skip to content
This repository has been archived by the owner on Mar 13, 2022. It is now read-only.

[RFC] Add test runners to project during quasar init #43

Open
8 of 19 tasks
nothingismagick opened this issue May 26, 2018 · 7 comments
Open
8 of 19 tasks

[RFC] Add test runners to project during quasar init #43

nothingismagick opened this issue May 26, 2018 · 7 comments

Comments

@nothingismagick
Copy link
Contributor

nothingismagick commented May 26, 2018

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:

  1. The user calls quasar init mypackage
  2. 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)
  3. These decisions are passed back to quasar-cli
  4. quasar-cli adds the mypackage/test folder, installs the base @quasar-test/base repo
  5. 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)
  6. As a post-install step, test-runner configs, src and output folders are copied or created in the mypackage/test folder.
  7. Where necessary, the mypackage/package.json is updated with configs for the test runners.
  8. Test commands are created in the mypackage/package.json, so that the user can run tests with yarn/npm.
  9. Where necessary, webpack-chain commands and aliases are added to mypackage/quasar.conf.js
  10. mypackage/.babelrc is updated accordingly
  11. Upon conclusion, the "test mode" is set and visible when the user runs quasar mode:

screen shot 2018-04-17 at 15 34 41

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

E2E

QUALITY

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

@nothingismagick nothingismagick changed the title [FEATURE] Add test mode during install, RFC [RFC] Add test mode during install May 26, 2018
@nothingismagick nothingismagick changed the title [RFC] Add test mode during install [RFC] Add test runners to project during install May 26, 2018
@nothingismagick nothingismagick changed the title [RFC] Add test runners to project during install [RFC] Add test runners to project during quasar init May 26, 2018
@Arushi-Jain
Copy link

Arushi-Jain commented May 26, 2018

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
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

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

@alansoliditydev
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants