jackstockley/ECE-Scholarships
1
0
Fork 0
mirror of https://github.com/jnstockley/ECE-Scholarships.git synced 2026-06-05 21:07:57 -05:00
Code Issues Projects Packages Wiki Activity
Page: Developer Documentation
Pages
Developer Documentation Home Sprint 1 Artifacts Sprint 2 Artifacts Sprint 3 Artifacts Sprint 4 Artifacts Sprint 5 Artifacts Sprint 6 Artifacts Story Backlog Tech Stack User Manual
1 Developer Documentation
Jack Stockley edited this page 2023-05-11 13:16:23 -05:00
Table of Contents

Procedure

Developers involved in the project shall follow guidelines listed below for their additions to be implemented into the functioning application. This guide outlines the standards and best practices required for your feature/task to be considered complete. This guide should also be used as reference for individuals reviewing another individuals code.

Pull Requests

A pull request MUST be submitted for the feature to be merged into develop branch. Please follow the guidance below for the various states of your pull request and best practice to prepare it for review.

Draft -> Public Review

When you create a pull request you should start the pull request as a draft. Pull requests shall target the develop branch always!

Requirements

  • Your branch shall have all action pipelines passing
  • Your branch shall have ALL areas of the template filled out
    • NOTE: Certain sections may be omitted with an N/A response however this N/A response must be accompanied by a reasoning. Ex: N/A (no forward facing changes to screenshot)
  • Your branch shall meet feature/task requirements (see User Acceptance)
  • The pull request shall be up to date with the develop branch
  • The pull request shall maintain the testing requirements (see Testing)

Review -> Merged

Once your pull request has moved from draft to 'ready for review', you must meet the following criteria before your branch can be merged into develop.

Requirements

  • The pull request shall meet all the requirements for Draft -> Public Review
  • The pull request shall have all threads resolved
  • The pull request shall have at minimum 2 accepted reviews

Once these requirements have been met, the developer may merge their changes into the develop branch.

Testing

We follow two testing strategies to ensure a wide coverage of our applications functionality. We are utilizing playwright to handle the end-to-end tests and pyunit for our unit testing. Coverage reports are produced automatically when running --tests all in our cli tool for running tests.

poetry run python -m tests.cli

adding --tests all is optional here (the default is all)

Requirements

  • Our tests shall maintain a C0 coverage of >75%
  • All new features added shall add testing to cover behavior
    • New code (ie function/class/file) shall have been partially covered by added testing
  • You shall follow test driven development principles, our tests will be written first
  • You shall follow the standards outlined for each testing framework below

End-to-End

poetry run python -m tests.cli --test playwright

Standards

  • New tests shall be placed in the project directory: tests/feature/
  • Large feature additions should have a dedicated folder labeled after the feature with smaller test files broken down inside the directory.
    • A 'large addition' is typically a feature with 3 or more points (use best judgement), or several pages added.
    • File names should make sense relative to the things it is testing and follow snake_case conventions
  • Tests shall be written as functions following the syntax test_name and follow snake_case format.
  • Test docstrings shall be written from the perspective of the user and outline what the test is attempting to achieve. Example Test:
def test_add_documents_in_sidebar():
   '''
   As I user, when I open the sidebar I shall see
   a link to the add documents page.
   '''
   # playwright tests here

Unit tests

poetry run python -m tests.cli --test pyunit

Standards

Branch Strategy

Always branch off of develop!

When working on a new feature

  1. Checkout develop branch
  2. Create new branch off of develop
  3. Merge develop changes periodically
  4. Create PR with base set to develop

When working on a release (end of sprint)

  1. Checkout develop branch
  2. Branch off develop, name the new branch with format: release_{version_number}
  3. Create PR for this branch with base set to main

User Acceptance

User Acceptance Criteria is added to each of the stories on Jira and also documented in the Sprint # Artifacts.

Versioning

To simplify versioning, we will tie versioning to our sprint number. For example, on sprint 1, our release version produced is version 1 and would therefore be named release_1.0. This format is considered major.minor where major represents sprint version and minor represents additional patches made to the sprint version (which shouldn't hopefully be necessary)