Skip to content
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

integrate jest #775

Closed
wants to merge 4 commits into from
Closed

integrate jest #775

wants to merge 4 commits into from

Conversation

MKaHead
Copy link
Contributor

@MKaHead MKaHead commented Jan 15, 2019

Jest Integration and necessary config changes

Changes proposed in this pull request:

  • regarding future Babel 7 and deprecated env key - add babelrc.js file, if babel 7 is integrated babelrc is obsolete

  • add jest, config, and jest runner script

  • add eslint jest recommented rules

  • remove babel external-helpers out of babel to fix issue, add it in rollup bundle proccess, but kicked out runtime helpers

  • add Documentation to Contribution file

Type of change

  • New feature (non-breaking change which adds functionality)
  • This change requires a documentation update

How Has This Been Tested?

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • [update]I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

@MKaHead MKaHead self-assigned this Jan 15, 2019
@MKaHead MKaHead requested review from LucaMele and AndyOGo January 15, 2019 12:01
package.json Outdated
@@ -173,5 +177,25 @@
"@ungap/custom-elements-builtin": "^0.1.1",
"document-register-element": "^1.12.0",
"react": ">=0.14.0"
},
"jest": {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I prefer to keep configuration scoped in separate config files.
May we moved it jest.config.js as described here: https://jestjs.io/docs/en/configuration.html

@@ -43,7 +43,8 @@ async function buildComponents() {
.then(result => result.css),
}),
babel({
runtimeHelpers: true,
Copy link

@AndyOGo AndyOGo Jan 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By removing this completely we loose reuse of babel-helpers:
https://babeljs.io/docs/en/6.26.3/babel-plugin-transform-runtime

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is an interesting read about how babel's cli and helper optimisation is working:
https://brunoscopelliti.com/a-simple-babel-optimization-i-recently-learned/

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately official docs are rather obscure:
https://www.npmjs.com/package/babel-plugin-external-helpers

const constants = require('../../constants');
const common = require('./_common');
const babel = require('rollup-plugin-babel');
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should import dependencies before relative files

@@ -19,10 +18,11 @@ async function buildApp() {
browser: true,
preferBuiltins: false,
}),
ENV === constants.ENV.PROD ? uglify() : () => {},
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uglify should happen after transpilation

Copy link

@AndyOGo AndyOGo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your PR, I really like jest.
Though I don't think it's the ideal test environment for custom elements.

May we discuss the drop of babel-runtime optimization.

@@ -43,7 +43,8 @@ async function buildComponents() {
.then(result => result.css),
}),
babel({
runtimeHelpers: true,
plugins: ['external-helpers'],
externalHelpers: true,
Copy link

@AndyOGo AndyOGo Jan 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

further info at rollup-plugin-babel

If you do not wish the babel helpers to be included in your bundle at all (but instead reference the global babelHelpers object), you may set the externalHelpers option to true:

By default externalHelpers option is set to false so babel helpers will be included in your bundle.

@LucaMele
Copy link
Contributor

@AndyOGo what framework would u suggest instead? we were also thinking to try mocha

@AndyOGo
Copy link

AndyOGo commented Jan 16, 2019

@LucaMele
Karma, mocha, sinon, snapshots with enzym for mocha and real DOM not VDOM

@LucaMele
Copy link
Contributor

@MKaHead ok lets stick to our original plan: Lets try Jest and Mocha/Karma etc and compare them.

The idea of using Karma is actually really good. We can so test various browser locally. I would also see if u can use Karma togheter with Jest.

So my suggestion is to evaluate JEST + KARMA + SNAPSHOT Capability VS Mocha + Sinon + Karma + Snapshot capability

@AndyOGo
Copy link

AndyOGo commented Jan 17, 2019

Agree.
Though as I understand Jest, it comes with a build-in test-runner within a Node environment only (no browser).
More info here:
https://jestjs.io/docs/en/configuration.html#testenvironment-string
jestjs/jest#139

@LucaMele
Copy link
Contributor

ok thanks @AndyOGo , i guess that will come up then in the evaluation

@AndyOGo
Copy link

AndyOGo commented Jan 17, 2019

So we are not the only team with that Jest problem of no browser environment.
There are solutions like:
https://www.npmjs.com/package/jest-browser

But only for headless chrome /~https://github.com/GoogleChrome/puppeteer

@LucaMele
Copy link
Contributor

@MKaHead also when runnning karma, when travis does the build then we can only test phantomjs. This could be a little issue. But anyway when running npm run release all the tests will done locally apart of Internet Explorer unless the releaser has a Windows PC which is very unlikley

@AndyOGo
Copy link

AndyOGo commented Jan 17, 2019

Agreed that's the other downside, CI/CD Pipeline support.

Ideally we would have a tooling which allows us to:

  • run tests in any browsers, concurrently
  • run tests within headless browsers, phantomjs, puppeteer, etc.
  • run tests directly in node, with fake API's like jsdom (for CI/CD speed)

All of that are different test environments.
And as said karma supports it all, like:
https://www.npmjs.com/package/karma-jsdom-launcher

@MKaHead MKaHead closed this Apr 16, 2019
@jackblackCH jackblackCH deleted the feature/testing-tool branch May 13, 2019 11:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants