Skip to content

Latest commit

 

History

History
101 lines (76 loc) · 3.98 KB

CONTRIBUTING.md

File metadata and controls

101 lines (76 loc) · 3.98 KB
Raw

Contributing

We would love for you to contribute to this project and help make it even better than it is today! As a contributor, here are the guidelines we would like you to follow. It does help everyone to accept your Pull Requests with maximum awesomeness:

Code of Conduct

Please read and follow our [Code of Conduct][coc].

General Seps

  1. Check if there is already an open issue for the subject;
  2. Open an issue to discuss the new feature;
  3. Fork this repository;
  4. Create your feature branch: git checkout -b feat/my-new-feature;
  5. Add files changed: git add --all;
  6. Commit your changes: git commit -m "feat: Add some feature";
  7. Push to the branch: git push origin feat/my-new-feature;
  8. Submit a pull request;

Commits and Pull Requests

  • ❌ AVOID breaking the continuous integration build.
  • ✔️ DO atomic commits to make it easier to analyze changes.
  • ✔️ DO keep pull requests small so they can be easily reviewed.
  • ✔️ DO only commit with conventional commit patterns

Conventional Commits

To know more about conventional commits, visit Conventional Commits.

In general the pattern mostly looks like this:

<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: *
  │
  └─⫸ Commit Type: feat|fix|docs|style|refactor|perf|build|test|ci|chore|merge|revert

Real world examples can look like this:

chore: run tests on travis ci

fix(server): send cors headers

feat(blog): add comment section

Common types you can use (based on the Angular convention):

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • build: Changes that affect the build system or external dependencies (example scopes: nugets, npm, SDKs, etc)
  • test: Adding missing tests or correcting existing tests
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • chore: Other changes that don't modify src or test files
  • merge: Merge a branch into other branch
  • revert: Reverts a previous commit

Coding Standards

  • ✔️ DO add XML comment documentation to new classes, methods or parameters.
  • ✔️ DO add a test class for each feature and a test method for each
  • ✔️ DO use language conventions to make code easy to understand quickly. See some tips here: dofactory;
  • ✔️ CONSIDER using SOLID patterns;

Tests

  • ✔️ DO add a unit test if your Pull Requests resolves an issue or adds features.
  • ✔️ CONSIDER using test patterns like "AAA" and "Given When Then";
  • ✔️ DO add a test class for each feature and a test method for each assertion;
  • ✔️ DO make sure unit tests pass.
  • ❌ AVOID adding tests just to get coverage on sonarcloud.

Disclaimer

  • 1️⃣ Unit in Unit Test is not a method/function.
  • 2️⃣ One assertion per test doesn't mean invoking the Assert method only once.

by @gsferreira