-
Notifications
You must be signed in to change notification settings - Fork 150
chore: enforce 100% coverage on CI #37
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
Conversation
46dd6f8
to
d18a8ea
Compare
"test": "jest", | ||
"test:local": "jest", | ||
"test:ci": "jest --coverage", | ||
"test": "is-ci test:ci test:local", |
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.
Curious as to why not simply running test:ci
on CI? It seems like an unnecessary setup for me... 🤔
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.
Mmm it's interesting: on one hand doesn't seem like a necessary dependency as you mentioned, but on the other hand it simplifies the execution of tests and external scripts to just npm test
without doing something special (we would have to customize travis job to execute test:ci
rather than default test
script). So I think is worth the cost of having this new dependency to simplify CI config around tests.
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.
If I'm not mistaken, the default Travis CI configuration for Node.js includes a test
script. I just didn't want to modify the CI config.
If it bugs you, we can put in the CI config. I think it boils down to personal preferences here 🙂
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 have these 2 seperated? if you want to run w/out coverage you can do --no-coverage
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.
It's fine, was just curious if there was some other reason 🙂
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.
@benmonro I usually prefer having 2 different tests scripts for local and ci just in case there are more things to set up for each (there is another project where I had to set some specific env vars and junit reporter), so it's easier to maintain in that way I think. And even better: it's transparent from executing the script with the package that Thomas added :)
@@ -1,3 +1,11 @@ | |||
module.exports = { | |||
testMatch: ['**/tests/**/*.js'], | |||
coverageThreshold: { |
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.
Didn't know that this already prevents CI from continuing as it makes jest fails if threshold is not met!
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.
Jest is awesome for that. Just set a coverage threshold and you're good to go as long as you run jest --coverage
!
🎉 This PR is included in version 1.3.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Closes #36