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.

Sign up for GitHub

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

chore: enforce 100% coverage on CI #37

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions jest.config.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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!

global: {
branches: 100,
functions: 100,
lines: 100,
statements: 100,
},
},
};
53 changes: 53 additions & 0 deletions package-lock.json
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

5 changes: 4 additions & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,9 @@
"lint": "eslint ./",
"lint:fix": "npm run lint -- --fix",
"format": "prettier --write README.md {lib,docs,tests}/**/*.{js,md}",
"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 •
edited
Loading

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 :)

"semantic-release": "semantic-release"
},
"dependencies": {},
Expand All @@ -46,6 +48,7 @@
"eslint-plugin-promise": "^4.2.1",
"eslint-plugin-standard": "^4.0.1",
"husky": "^3.0.5",
"is-ci-cli": "^2.0.0",
"jest": "^24.9.0",
"lint-staged": "^9.2.5",
"prettier": "1.18.2",
Expand Down