Skip to content

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

Merged
merged 1 commit into from
Oct 28, 2019
Merged

Conversation

thomaslombart
Copy link
Collaborator

@thomaslombart thomaslombart commented Oct 28, 2019

Closes #36

@thomaslombart thomaslombart requested a review from Belco90 October 28, 2019 12:01
@thomaslombart thomaslombart self-assigned this Oct 28, 2019
"test": "jest",
"test:local": "jest",
"test:ci": "jest --coverage",
"test": "is-ci test:ci test:local",
Copy link
Contributor

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... 🤔

Copy link
Member

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.

Copy link
Collaborator Author

@thomaslombart thomaslombart Oct 28, 2019

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 🙂

Copy link
Member

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

Copy link
Contributor

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 🙂

Copy link
Member

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: {
Copy link
Member

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!

Copy link
Collaborator Author

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!

@Belco90 Belco90 changed the title test: enforce 100% coverage on CI chore: enforce 100% coverage on CI Oct 28, 2019
@Belco90 Belco90 merged commit 01bd33b into master Oct 28, 2019
@Belco90 Belco90 deleted the test/enforce-coverage branch October 28, 2019 19:47
@Belco90
Copy link
Member

Belco90 commented Oct 31, 2019

🎉 This PR is included in version 1.3.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Successfully merging this pull request may close these issues.

Code coverage improvements
4 participants