Skip to content

Latest commit

 

History

History
78 lines (54 loc) · 3.08 KB

CONTRIBUTING.md

File metadata and controls

78 lines (54 loc) · 3.08 KB

Contributing to ADF

Submitting a Pull Request (PR)

Before you submit a pull request please follow the steps below:

  • Search in GitHub PR for an open or closed PR that could solve or already solves your issue.

  • Search in the GitHub release history to see if your issue has already been solved in a new version of ADF.

  • Fork our repository (if you don't know how to do this, read this GitHub document).

  • Make your changes in a new git branch starting from develop and following our naming convention

    git checkout -b dev-{developerName}-{GitIssuedId/JiraIssueId} develop
  • Create your PR including appropriate test cases following the code contribution acceptance criteria

  • Run the tests and make sure they are green. Please don't comment out or exclude the tests that are already in place.

  • Commit your change using the commit format message good practice

  • Push your branch to GitHub:

    git push origin dev-{developerName}-{GitIssuedId/JiraIssueId}
  • In GitHub, send a pull request to develop.

  • If we suggest changes then:

    • Make the required updates.

    • Re-run the tests.

    • Rebase your branch and force push to your GitHub repository (this will update your Pull Request):

      git fetch develop
      git checkout dev-my-branch
      git rebase develop -i
      git push -f

Note: If you need more information about how to sync your fork, see this page.

Code style

The code style for ADF follows the Angular style guide plus some internal rules.

The codebase is also checked with:

  • ESLint tool
  • Stylelint tool

Test guide

In ADF, we encourage the use of behavior-driven development (BDD).

General guidelines

  • Class selector in all the tests is not suggested. Use of the element ID is preferred
  • Any test case should test only one behavior
  • Use of the Angular testBed is highly recommended

File name

  • The file name specification must be the same as the component/service/pipe it tests plus the .spec. suffix.
  • The specification file must be in the same folder as the component/service/pipe it tests.

Describer Name

  • The Main describer of the test should be the name of the class under test
  • The sub describe is used for grouping related behavior test. Do not overuse it.

Test Name

Any test should follow the naming convention:

[Should] [ Expected Behavior ] [when/after/before] [ State Under Test ].