Skip to content

Latest commit

 

History

History
62 lines (50 loc) · 4.56 KB

README.md

File metadata and controls

62 lines (50 loc) · 4.56 KB
Raw

https://wethefoodies-329cf.web.app/login.html

12DaysOfCoding

CI CD Codacy Codacy Badge

Project Description

Our team will design a recipe management application.

Setup Instructions

  1. git clone https://github.com/12DaysOfCoding/WeTheFoodies.git
  2. Get nodejs if you don't already have.
  3. In the root dir of this project, run npm install. This will install ESLint and Jest.
  4. To run the linter, do npm run lint. Only unfixable problems will be reported.
  5. To run unit tests, npm run test
  6. To run e2e tests, npm run e2e

Contribution

  1. Make changes in the folder called source, more specifically, the html files are placed directly inside the source while the css and js files are placed inside assets/style and assets/scripts respectively.
  2. Run npm run lint to lint the code up to standard.
  3. Follow the testing writeup, add more unit and end to end tests to the corresponding folder (highly recommended).
  4. Run npm run test to execute unit tests. Fix any issue.
  5. Run npm run e2e to execute end to end test. Fix any issue.
  6. Commit all changes and push.
  7. Make a pull request and fill out the template. Request some reviews.
  8. Make sure all status checks are passed before merging

Testing

  • We are using a combination of Jest and puppeteer to run tests.
  • Jest is for unit tests and puppeteer is for end to end tests.
  • Note there is a folder call /tests in the root dir. Within this folder, you have one folder called unit and another called e2e. Each contains an example of how to write a simple test.

Documentation

This is auto generated by JSDoc You need to follow their guideline (preceding functions with a line or block comment) in order for the documentation to show up. Ex.

/**
 * returns the sum of a and b
 * @param {int} a - first number
 * @param {int} b - second number
 */
const add = (a, b) => a + b;

Linting

  • Ideally, make sure to lint locally before make the pull request. But it's fine to just push to repo, since CI pipeline would lint again just in case.
  • We are using ESLint as linter.
  • Only files within the "src" directory would be linted.

Quality analysis automation

  • We are using Codacy to analysis the quality of the source code.
  • For each pull request, the CI/CD pipeline (this file in particular) would automatically enable Codacy and perform analysis as needed.
  • Codacy also provided us the dashboard to monitor various aspects of the project, including code duplication, complexity, etc.

Reason to avoid hiding API keys: Although we had originally wanted to hide our API keys within our codebase, we have concluded that it would be better to direct our efforts else where. Our project has two API keys: Spoonacular and Firebase. In regards to the Spoonacular API we concluded that it would not be detrimental to security to expose this key. Spoonacular is a free public API with only GET capabilities. Upon further research, we found that exposing the Firebase key is not a security risk. This key is an identifier for our database and with our Firebase security rules limiting access to an authenticated user’s own data, there is little risk of abuse. Although we had originally planned to hide these keys out of code practice, we realized that with the time we had sunk into finding a solution as well as our value of simplicity, it would be best to keep our project in its original form of vanilla javascript. This allowed us to redirect our efforts elsewhere rather than spend more time re-working our project to support environment variables.