Branch name convention, an example

 

 

 Branch name convention

 

1. Prefix with ticket number: Start the branch name with the ticket number associated with the task or issue being addressed. This ensures that branches are easily identifiable and linked to specific tickets in the project management system.
2. Use hyphens for readability: Separate the ticket number from the branch description using hyphens for readability. This helps team members quickly understand the purpose of the branch without having to inspect its contents.
3. Use descriptive branch names: After the ticket number, provide a brief but descriptive name for the branch that summarizes the changes being made. This can include keywords related to the feature, bug fix, or enhancement being implemented.
4. Limit length: Keep branch names concise to avoid excessive verbosity. While it's essential to provide enough information for clarity, overly long branch names can become cumbersome and difficult to manage.
5. Lowercase and dashes: Stick to lowercase letters and use dashes instead of spaces in branch names to ensure compatibility across different operating systems and Git hosting platforms.

 

Branch conventions

Format: <type>/<JIRA issueNumber>-<description>

Example: feature/RSDE-2389-add-user-authentication

• feature indicates that it's a feature branch.
• rsde-2389 is the ticket number associated with the task → Jira task number
• add-user-authentication provides a clear description of the changes being made.

Git branch prefixes

Using prefixes in branch names is a popular strategy to categorize branches based on their purpose:

 

Git Branch Prefixes

Prefix	Purpose
Prefix	Purpose
feat/	New features
fix/	Bug fixes
chore/	Maintenance tasks
docs/	Documentation updates
refactor/	Code refactoring
test/	Adding or updating tests
hotfix/	Urgent fixes (e.g., production)
release/	Release preparation
perf/	Performance improvements
style/	Code style or formatting changes
ci/	CI/CD pipeline updates
build/	Build process or dependency changes
wip/	Work in progress
revert/	Reverting commits

 

---

Repository model for AI-QA

• main: Main branch
• chore: ORT copies
• wip : Work in progress, after a while it can be wiped out safely
• feat, docs, fix, ci: All these could end into a pull request and then be deleted

Example

# Main branch main # Ort copies, NS -> No Story chore/ NS_2024_11_05_ort_branch NS_original_ort_branch # Work in progress, after a while it can be wiped out safely wip/ NS_last_version_without_id # All these below would end into a pull request and then be deleted feat/ RSDET-1234_adding_a_great_feature docs/ RSDET-1332_documentation_readme fix/ RSDET-3333_nasty_bug ci/ RSDET-4444_add_plugin_to_Jenkins

Best Practices for Branch Naming

1. Keep branch names descriptive yet concise:
• Example: feat/add-user-authentication is better than feat/auth.
2. Separate words with hyphens:
• Example: fix/typo-on-homepage instead of fix_typo_on_homepage.
3. Use prefixes consistently:
• Always use the same prefixes for similar tasks.
4. Avoid personal identifiers:
• Instead of john/fix-login, use fix/login.
5. Include ticket/issue IDs when applicable:
• Example: feat/PROJ-123-add-dashboard.

 

 

Pull request conventions

Pull Request Naming Convention

The PR title should summarize the changes in a concise and clear manner.

Naming convention: Pull request title should be: <type>: [JIRA issueNumber] <description>

where

<type> - one of following [optional scope] - additional information
<JIRA issueNumber> - Jira issue number in brackets or NS for no story
<description> - description of pr

Examples:

✅ Good Titles:

• feat: [RSDET-1234] Add user authentication module
• fix: [RSDET-1223] Resolve login page crash on invalid input
• chore: [RSDET-1234] Update dependencies for security fixes

❌ Bad Titles:

• fix bug
• new feature
• updates

 

Prefixes:
FYI: Key Differences Between Branch Prefixes and Pull Request Prefixes

Aspect	Branch Prefixes	Pull Request Prefixes
Purpose	To categorize branches based on the type of work (e.g., feature, bugfix, chore).	To provide context about the change in the PR (e.g., new feature, bug fix, refactor).
Scope	Defines branch content and usage.	Describes the overall change set or purpose of the PR.
Relation to Workflow	Tied directly to Git branching strategies.	Used in review processes, linked to task tracking systems like Jira.

Les bonne pratiques du développement - projet LQ

 Clean Code et bonnes pratiques 

Règles générales concernant la longueur des classes et méthodes 

1. Les méthodes devraient avoir au plus 20 lignes 

2. Les classes devraient avoir au plus 200 lignes 

3. Une classe devrait contenir au plus 10 méthodes 

4. Plus les méthodes et les classes sont grandes, moins elles sont réutilisables 

Principe de proximité 

Regrouper ensemble une méthode publique avec ses méthodes privées 

Permet de lire le fichier comme un journal : Grand titre = méthode publique, sous-titres = méthodes privées, etc. 

Éviter les régions 

Moyen artificiel d'organiser les fichiers 

Dissimulent la véritable longueur d'un fichier et sa complexité

 Ne valent pas mieux que les commentaires si on les compare au code auto-documenté

 

Architecture hexagonale

Aussi connue sous le nom d'architecture en oignon ou encore ports et adaptateurs, l'architecture hexagonale est articulée autour d'un noyau représentant le domaine d'affaires, sur lequel une couche de composants d'infrastructure est greffée

Architecture hexagonale générale.

version 2020

Scrum by Jeff Sutherland

I recently finished the book Scrum by Jeff Sutherland and even though that is a book from 2014 I think is still relevant in the basic topics.

Here my notes and highlights of the book :

The second part.of the book which touches the education , social and government spheres and the impactmof Scrum on it.

Règles sur le tests unitaires dans un projet x

------------ TEXTE

Bonne pratiques

Structure des Triple A

• Arrange, Act, Assert

• Les sections du test doivent être indiquées par un commentaire

[Fact]

public void ExempleStructureTripleA_AvecCommentaires()

{

    // Arrange

    // Act

    // Assert

}

Section Arrange

• Contient tout ce qui est nécessaire pour mettre en place les éléments nécessaires au test

o Création de l'élément de programme testé (SUT- ou System Under Test)

o Arguments

o Résultat attendu s'il y a lieu (pourrait aussi être fait dans la section Assert)

o Exécution d'autres méthodes ou fonction

Section Act

• Exécution de l'élément de programme testé

o Appel d'une méthode

o Exécution d'une fonction qui soulève une exception

o etc.

• En général une seule ligne de code

Section Assert

• Contient les assertions nécessaires à la vérification du comportement attendu

Quoi tester?

• En boîte noire, donc pas de test pour les méthodes privées, seulement les méthodes publiques

Comportement de l'élément de programme

• Comportement : Résultat produit par la fonctionnalité d'un élément de programme en fonction de certaines préconditions

o Préconditions : généralement l'intrant de l'élément de programme

o Résultat produit = Postconditions + effets de bord

Questions à se poser

• Quelle forme peut prendre l'intrant de l'élément de programme testé?

o Est-ce que toutes les valeurs permises ont été spécifiées?

• De quelle façon le succès ou l'échec est-il communiqué?

o Réaction aux intrants invalides

 Recouvre?

 Crash?

o Comportement inhabituel ou inattendu?

Assertions

Définition

• Ce sont des vérifications

• Est-ce que l'élément de programme se comporte tel qu'attendu?

o Est-ce que l'élément de programme fait ce qu'il est supposé faire?

o Est-ce que l'élément de programme ne fait PAS ce qu'il n'est pas

supposé faire?

• Vérifier le comportement

o Par la vérification du résultat produit, qui peut être

 Une valeur de retour

 Un changement à l'état du système (effet de bord)

 Un appel à un contributeur

Quantité d'assertions nécessaire

• Idéalement : une seule assertion à la fin du test

• Les assertions multiples ajoutent de la complexité avec peu de valeur et rendent plus difficile l'identification du véritable problème

o Le test s'arrête dès la première assertion en échec

o Les assertions suivantes ne sont alors pas exécutées, se qui rend le diagnostique du problème incomplet

Quantité d'assertions nécessaire : Exceptions

Assertion de garde

• Une assertion de garde est une vérification de sécurité qui permet d'éviter d'avoir de la logique conditionnelle et protège des erreurs à l'exécution

• Exemples :

o Vérifier que le retour d'une méthode n'est pas null avant de faire d'autres assertions

o Vérifier le nombre d'éléments d'une collection avant d'accéder aux éléments

• Donc pas de if-else dans les tests!

Un concept sémantique qui n'est pas vérifiable par une seule assertion

• Par exemple, la vérification des éléments d'une collection pourrait nécessiter une assertion par élément

• Il existe des outils dans ce cas-ci

o FluentAssertions permet la vérification d'une collection avec une seule assertion, ainsi que CollectionAssert de MSTest

Noms des tests et gabarit

• Gherkin, style BDD

o ÉtantDonné_Lorsque_Alors

o Méthode_Contexte_RésultatAttendu

• Sous-classes de tests avec nom méthode testée

o Permet de renommer facilement si méthode renommée

o Organise les tests

public class SutTests

{

  public class UneMethode

  {

    [Fact]

    public void Contexte_RésultatAttendu()

    {

      \...

    }

  }

  public class UneAutreMethode

  {

    [Fact]

    public void Contexte_RésultatAttendu()

    {

      \...

    }

  }

}

Éléments à considérer

• Résistance au réusinage -\tenir au minimum l'utilisation des mocks

• Penser à la maintenabilité des tests : aussi important que le code de production

o Retour sur investissement vs coûts de maintenance des tests

o Cibler les parties les plus importantes de la base de code ->Domaine d'affaires

• Les mêmes règles de Clean Code / Bonnes pratiques s'appliquent ici!

o Code auto-documenté, clair, concis, expressif, etc.

o L'intention du test peut être comprise rapidement

Code ciblé

Domaine d'affaire

• Idéalement 100% de couverture de code

Infrastructure

• Repousser aux limites de la composante les I/O et effets de bord

• Couvrir les cas principaux (Happy path et Sad path)

Couverture de code

• Ne pas exclure de code de la couverture pour avoir la vérité en tout temps

Comportement vs interaction : Mocks

Pourquoi

• Pour isoler un élément de programme de ses dépendances sortantes

Quand

• Lorsque le contributeur est une dépendance sur laquelle nous n'avons pas le contrôle

o BD
o Service externe (SAGO, Moneris, etc) Système de fichier
o Librairie patrimoniale non
o etc.

Comment

• Principe : substituer la dépendance gênante pour un simulacre

o Si cette dépendance implémente une interface, doubler (mocker) cette interface

o Sinon, ajouter une couche d'abstraction supplémentaire devant cette dépendance, qui agira comme une sorte de proxy et qui deviendra la nouvelle dépendance de l'élément de programme testé

• Utiliser un framework d'isolation comme FakeItEasy

Bonnes pratiques

• Un seul mock par dépendance par test

• Une seule assertion sur le mock par test

o Vérifier soit le comportement, soit les interactions, mais pas les deux

• Éviter les new dans les objets gérés par injection de dépendances

• Repousser ces dépendances aux frontières du système (couche d'infrastructure) et garder le domaine d'affaires le plus pur possible

Tests paramétrés

• Ces tests sont pratiques pour spécifier par l'exemple

Exemple

private const string ouvertureSpan = "<span style=\"border-bottom: 4px solid #f19e8f; width: 6px">; 

private const string fermetureSpan = "</span>";

public static IEnumerable<object>ScenariosTest() => new[]

{

    new object[] { "", $"{ouvertureSpan}{fermetureSpan}" },

    new object[] { " un deux", $"{ouvertureSpan}{fermetureSpan} un deux" }, 

    new object[] { "t un deux", $"{ouvertureSpan}t{fermetureSpan} un deux" },

    new object[] { "te un deux", $"{ouvertureSpan}te{fermetureSpan} un deux" }, 

    new object[] { "test un deux", $"{ouvertureSpan}tes{fermetureSpan}t un deux" },

    new object[] { "testtest un deux", $"{ouvertureSpan}tes{fermetureSpan}ttest un deux" },

};

[Theory, MemberData(nameof(ScenariosTest))]

public void SelonTexteEnEntree_VerifierChaineHtmlAttendue(string texte, string chaineHtmlAttendue) 

{

    var htmlHelper = CreerHtmlHelper();

    var resultat = htmlHelper.SoulignerTroisPremieresLettres(texte);

    

    resultat.Should().Be(chaineHtmlAttendue);

}

Creating some Unit tests with xUnit, FakeitEasy and FluentAssertions

 

As you can see here a very basic sample of a unit test created for a notification service on a ASP.net MVC 5 solution.

Here the code to test a failing list of emails.

[Fact]

            public void ListeCourrielsEstValide_ListeInvalide_RetourneErreur()

            {

                //Arrange

                IEnumerable<string> listeCourriels = new string[] { "123%xer;456#wer;yuio!879" }; 

                bool valeurAttendu = false;

                //Act

                var resultat = notificationService.ListeCourrielsEstValide(listeCourriels);

                //Assert

                resultat.Should().Be(valeurAttendu);

            }

Le Front-end dans la vie public. Règles de conception pour les styles (CSS)

 

Règles de conception

Balises principales :

• On n'écrit pas de CSS;
• On utilise des composants qui existent dans les librairies des développeurs;
• On veut quand même arriver avec un visuel qui semble au système de design du gouvernement.

Pour y arriver, pendent la conception des maquettes, on se serve concrètement des composants Bootstrap et Kendo UI (dans cet ordre) sauf si le composant de Quebec.ca n'est pas trop lois de ces composants.

On attente le moment où on peut juger l'utilisation de certains composants certain et stable, pour affiner le thème, si ces composants ne semblent pas assez au système de design.

Technologie UI générale

• Framework : Kendo UI for MVC (pas de SPA); On crée un thème pour Kendo UI/Bootstrap, et on crée qu'un minimum de CSS.
• Hyperliens pour une section du formulaire ou une question, et pour la page de connexion
• Navigation historique entre vues marche (bouton retour plutôt que reset)
• La session est suffisamment longue (20h idéalement; 1h min.)
• HTML 5 (CSS 4, 5), l’interaction peut être différent dépendent des capacités du navigateur (progressive enhancement)
• Enregistrement des sections sans remplir tout le champs obligatoires et sans soumettre la demande
• Confirmation de navigation s'il y a des changements non-enregistrés
• HTTPS partout
• Validation des formats des champs et obligatoires au moins par JavaScript, sur blur (inline)
• Soumission implicite sur touche Entrée dans les champs
• Les formats d'affichage doivent toujours être accepté comme format d'entrée, particulièrement sans et avec espaces, pour permettre copier-coller
• Limites des charactères généreux ou sans limite pour permettre des espaces ou des cas extrêmes (Consultation)
• Performance comparable à AJAX (Turbolinks/SPA) souhaitable
• Aperçu des fichiers souhaitable, avant le téléversement encore mieux

a11y

• HTML sémantique
• Tests avec clavier
• Tests avec un lecteur d'écran
• SGQRI 008 2.0 

Textes

• Si un article de la loi est mentionné, mettre un lien vers l'article chez legisquebec.ca
• Les abréviations sont expliqués (premier occurrence avec parenthèses)
• Pas des formulations négatives
• Les signes de ponctuation, si nécessaire, sont séparé par un espace fine, ou au moins avec un espace insécable

Déjà utile

• Kendo UI (Telerik for APS.NET MVC) 
• Stratégie de transformation numérique gouvernementale 2019-2023 
• Dix principes de conception 
• Sondage 5 minutes pour contribuer à la transformation numérique gouvernementale 
• Implementing a citizen-centric approach to delivering government services 
• WCAG Quick reference 
• SGQRI 008 2.0 
• PIV  gouvernement:gouv@piv
• Systeme de design Quebec.ca 
  • Accordéons 
  • Retour en haut de page 
  • Notes  et exemple mobile 
  • À consulter aussi 
  • Champs texte 
  • Champs obligatoires 
  • Fil d’Ariane 
  • Images 
  • Tuiles  (en développement)
  • Menu déroulant  (en développement)
  • Infobulles  (en développement)

Regardé

• Lion Web Components 
• 9 Web Components UI Libraries You Should Know in 2020 
• Stimulus JS 
• Bootstrap