- Click the
Use this templatebutton on the top right - Click on
Settings > Code security and analysis- Enable
Dependabot alerts - Enable
Dependabot security updates
- Enable
- Update badges at the top of the
README.mdto point to your new repositories GitHub Action results




- Clone your new repository
- Update the
nameof your application in thepackage.jsonfile in the root of your repository - Run
npm install
This starter template bootstraps your repository with coding standards, industry best practices and detects security vulnerabilities. This template provides fast code analysis and automated testing feedback loops so you can focus on solving problems.
This template uses ESLint to analyze the code in this repository.
To run ESLint run the command npm run lint. ESLint can also automatically fix problems by running npm run lint:fix.
If you are using VSCode adding the ESLint (dbaeumer.vscode-eslint) plugin provides live feedback as you are writing code. Faster feedback loops help team members learn team style guidelines faster and avoid delays while committing.
It's all too common for developers to accidentally commit usernames and or passwords into their repository. This can lead to significant security vulnerabilities and even lead to security breaches. Secretlint is a pluggable linting tool that prevents developers from committing their credentials. Secretlint is configured in the .secretlintrc.json file at the root of this repository.
To run Secretlint run the command npm run secretlint.
Products that are test driven have lower defect rates. Teams that distribute test coverage according to the testing pyramid build products that are easier to change. The App.test.js test uses the React Test Renderer which uses the React framework to render a Component. The use of React Test Renderer integrates the framework's rendering capabilities with the plain App.js component. Therefore, this test fits in the middle of the pyramid. These tests are a bit slower and more costly to maintain than completely isolated unit tests at the bottom of the testing pyramid.
Cypress tests fit at the top of the testing pyramid. They are the slowest to run and the most expensive to write, run and maintain. Nevertheless, these tests are vital for the success of any healthy product. Teams should limit these tests to 5 - 10 of the most common happy paths through the product. To run Cypress test open a terminal window and run npm start to start the application. Once the application is started, open a second terminal window and run npm run cypress:run. If you wish to use the Cypress Launchpad run npm run cypress:open instead.
Test automation is essential for longterm product health. Each test exercises the application and ensures that it behaves the way that the customer expects. As products grow it's not uncommon to have tens of thousands of unit tests that run in a few milliseconds. Beyond unit tests teams invest in integration tests and user interface testing. Teams that are committed to test driving code often write thoughtful tests that provide comprehensive product test coverage.
Code coverage verification can be useful for teams to identify test coverage holes within their product. These thresholds simply identify if a line of code was exercised by a test. However, it cannot determine if the test coverage is exercising the code in a meaningful way. Code coverage thresholds only identify test coverage gaps and should not be used as a substitute for a strong team culture of test driving code.
This repository uses the React Testing Library. By default React Testing Library is configured to use Jest under the hood. Within Jest, test coverage thresholds are set in the jest.config.js file at the root of this repository.
Cypress tests are not included in code coverage metrics. End-to-end, full-stack integration tests often touch significant amounts of code without providing the level of coverage that thoughtful unit or integration tests provide lower in the testing pyramid. While they serve a crucial role in holistic testing, they don't contribute to test coverage calculations.
This template uses Husky to verify the code before it’s committed to git. The .husky/pre-commit file is run before a git commit is completed.
Before each commit, Husky checks for secrets within the code. If a secret is found it will stop the commit and will require the secret to be removed from the commit. Committing secrets is a very common mistake and must be avoided.
This template uses GitHub Actions to run continuous integration builds after each push and pull request within GitHub.
.github/workflows/codeql-analysis.ymlsets up code scanning for your repository..github/workflows/node.js.ymlruns tests against your code..github/workflows/cypress.ymlruns cypress tests against your code..github/workflows/linting.ymlruns ESLint against the code along with secretlint