Thursday, December 1, 2022

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é

Tuesday, October 18, 2022

Architecture hexagonale

 


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








Wednesday, July 20, 2022

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.


















Friday, November 12, 2021

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);

}















Tuesday, June 15, 2021

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);
            }






Wednesday, May 12, 2021

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

Regardé

Monday, April 26, 2021

backup post - QC MTL job salaries 2020.

Some pics of job salaries for IT positions.



Also some wafers for those coffee brakes.