-
Notifications
You must be signed in to change notification settings - Fork 356
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
Allow ES6 based tests using jest #2540
Conversation
/cc @vojtechszocs |
d9ba490
to
91a53a3
Compare
Jest is much more than that 😄 it's converging to become a test platform, beyond a simple test runner. Jest does stuff like ES6 to ES5 transpilation using existing Babel configuration, which means you don't have to "webpack + run tests", you just "run tests". Simply put, Jest handles the tests and webpack handles the build. |
.babelrc
Outdated
"presets": [["env", { "modules": false }]], | ||
"env": { | ||
"test": { | ||
"presets": [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a preparation for the future, to allow test-specific Babel configuration, right?
@@ -0,0 +1,5 @@ | |||
test('it should log to the console hello angular', () => { | |||
window.console.log = jest.fn(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a side effect which should be restored after the test finishes its execution (it's usually better to do this in beforeEach
and afterEach
though):
const restore = window.console.log;
window.console.log = jest.fn();
require('./application-common');
expect(window.console.log).toBeCalled();
window.console.log = restore;
package.json
Outdated
@@ -4,7 +4,9 @@ | |||
"description": "ManageIQ Cloud Management Platform", | |||
"main": "index.js", | |||
"scripts": { | |||
"test": "echo \"Error: no test specified\" && exit 1" | |||
"test": "node node_modules/.bin/jest", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why node node_modules/.bin/jest
and not simply jest
?
AFAIK, when executing scripts defined in package.json
via npm run
or yarn run
, executables in node_modules/.bin
are added to the path automatically.
package.json
Outdated
@@ -73,5 +78,28 @@ | |||
"node": ">= 6.9.1", | |||
"npm": ">= 3.10.3", | |||
"yarn": ">= 0.20.1" | |||
}, | |||
"jest": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd strongly suggest not to pollute your package.json
with dependency-specific configuration.
See this AVA issue where people asked for an alternative configuration method and were denied just because the maintainers weren't open minded enough. If you'd put all your Babel, Jest, etc. configuration into single package.json
, you'd end up with a huge JSON file, mixing project definition (metadata, dependencies, etc.) with dependency configuration while also being limited to the static nature of JSON while also not being able to reuse/align those configurations across different projects.
A much better way is to create a separate file, like jest.config.js
, that contains Jest related configuration. Plus, since it's .js
it can contain logic as well.
package.json
Outdated
@@ -73,5 +78,28 @@ | |||
"node": ">= 6.9.1", | |||
"npm": ">= 3.10.3", | |||
"yarn": ">= 0.20.1" | |||
}, | |||
"jest": { | |||
"automock": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why enable auto-mocking? IMHO explicit, selective mocking of modules is much better.
Note that auto-mocking was turned off by default since Jest 15.
package.json
Outdated
"__testing__": true | ||
}, | ||
"transform": { | ||
"^.+\\.js$": "babel-jest" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Custom transform
isn't necessary, unless you're using extra preprocessors, see here.
package.json
Outdated
}, | ||
"roots": [ | ||
"app/javascript/packs" | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd explicitly specify which files should be picked up for testing, something like:
testMatch: ["**/*.test.js"]
package.json
Outdated
"lcov" | ||
], | ||
"moduleNameMapper": { | ||
"^.+\\.(png|gif|css|scss)$": "identity-obj-proxy" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd usually mock binary assets, like images & fonts, like this:
"\.(png|jpg|gif|svg|eot|ttf|woff|woff2)$": "jest.mock.static-file.js"
where the file mentioned above would contain
'use strict';
module.exports = 'static-file-stub';
so that when someone import
s a binary asset in JS code, he gets back the static-file-stub
string.
TL;DR not sure if identity-obj-proxy
is worth using on binary assets.
@vojtechszocs in the meanwhile I'm taking a different approach at https://github.com/ohadlevy/miq_experimental_ui_plugin - please let me know what do you think about the defaults in that project. current blocker I've seen is that travis doesn't know how to run multiple languages in the same project, e.g. you can either have a ruby matrix or a node matrix - not both. |
This pull request is not mergeable. Please rebase and repush. |
e8ecba2
to
52e10f7
Compare
@vojtechszocs can you please have another look? |
0de70ff
to
d0836c2
Compare
I've left a failing test so we can see it actually failing, once you approve I'll fix the test. |
also add missing tests for component registry and enable eslint configuration for react.
@@ -1,5 +1,8 @@ | |||
{ | |||
"presets": [ | |||
["env", { "modules": false } ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any idea why we had modules: false to begin with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/rails/webpacker/blob/master/lib/install/config/.babelrc#L4 is the only reason I think.
(Mostly our webpack config is just webpacker default.)
@@ -15,6 +15,7 @@ env: | |||
- TEST_SUITE=spec | |||
- TEST_SUITE=spec:javascript | |||
- TEST_SUITE=spec:compile | |||
- TEST_SUITE=spec:jest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was unable to find a way to have a different language (besides ruby) for travis to run while keeping the ruby one, this means we execute the tests as a rake task under ruby environment, however I believe this is exactly how jasmine tests run today.
It has a few disadvanteges:
- setup installs the entire environment, when in fact we only need yarn (adds about 10 minutes to the test)
- we run jest twice with two different rubies.
- we can't run with different node version.
@skateman - you once mentioned you know of a way to run travis with different language matrix... any idea? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@skateman thanks - the way I read it:
- we can do it, but it means we have to revisit/update how we use travis today.
- not in this PR :)
Any chance we can keep the tests nicely separated from the code as we have now? Say, Otherwise, LGTM, but the test failure is relevant ;). |
Sure we can, but i have a few reason why i suggest this way:
Would you be willing to give it a try? We can always switch afterwards.
You mean the hello angular test? I left it on purpose so you can see its actually failing - happy to remove if you ack. |
OK, I don't really have a strong opinion about the separation, I consider it useful because when searching, you usually only care about code, not specs and if those are together, it can get annoying to keep seeing specs in search results. But I can set my search tool to ignore
Aah, then yup, this looks promising :) It actually looks readable in the travis output.. (for posterity, this is how it looks) Feel free to remove, I still want to give this a spin locally to see how it works in a browser, but IMO LGTM. |
@himdel I've removed the faling test - if someone wants to see it have a look at https://travis-ci.org/ManageIQ/manageiq-ui-classic/jobs/334595691 I also added a commit which fixes linting errors due to new the configuration. |
Running the whole test suite:
Running a specific test:
Running with debugger enabled:
(Which will do..
and then there's a green button in chrome's inspector, or a list in EDIT: Apparently there's no way to make chrome open the right thing from the script, but I guess .. we should add this info somewhere in guides. |
Some comments on commits ohadlevy/manageiq-ui-classic@02394a2~...41db8b0 Rakefile
|
@himdel added task:
|
Checked commits ohadlevy/manageiq-ui-classic@02394a2~...41db8b0 with ruby 2.3.3, rubocop 0.52.0, haml-lint 0.20.0, and yamllint 1.10.0 Rakefile
|
Thanks, waiting for travis.. :) |
jest testing support for miq
also add missing tests for component registry and enable eslint configuration for react.