Création d'une Pull Request

/!\ This page documenting our PRs process is in french.

PRs et non-régression

On découpe au maximum les PRs, pour faciliter la revue de code par les pairs. Ce n'est pas grave d'avoir plusieurs tickets dans une seul PR si le nombre de lignes modifiées n'est pas trop important.

• Si la PR est une correction/bugfix :
  • Si la correction est testable en test unitaire : on doit trouver des tests unitaires dans la PR
  • Si la correction est non testable en test unitaire : on doit trouver des tests e2e
• Si la PR est une fonctionnalité :
  • Ajouter un test e2e si la fonctionnalité est de taille moyenne (ex. ajout d'une fonctionnalité non existante) pour s'assurer de la non-regression dans le futur du scénario
    • On développe un test Cypress d'un scénario simple (pour ne pas rendre cette tâche contraignante)
    • S'il y a un bug par la suite: on rajoute un autre scénario dans un nouveau test Cypress
  • Ajouter un test unitaire si la fonctionnalité est testable unitairement et n'est pas nouvelle