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 

backup post - QC MTL job salaries 2020.

Some pics of job salaries for IT positions.

Also some wafers for those coffee brakes.

Goodhart’s Law on Software Development

Goodhart's law is an adage named after British economist Charles Goodhart, who advanced the idea in a 1975 article on monetary policy in the United Kingdom, Problems of Monetary Management: the U.K. Experience (wiki 2020) 

There are numerous concepts related to this idea, at least one of which predates Goodhart's statement of 1975

Clean Code et bonne pratiques en général

 

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é

Créer une branche de feature dans Visual Studio et Azure DevOps

Sur Visual Studio

1. Basculer sur la branche master.

   • S'il y a des modifications dans la branche courante, il faudra les valider (commit) ou les annuler (undo) avant de basculer sur master.

2. Tirer la dernière version de la branche master.
   
   

3. Créer une nouvelle branche à partir de la branche master locale et la nommer selon la règle de nomenclature.
   
   

Sur Azure DevOps

1. Sélectionner New Branch à partir de la branche master.
   
   

2. Nommer la branche selon la règle de nomenclature.
   
   

3. Tirer la nouvelle branche sur Visual Studio

   • S'il y a des modifications dans la branche courante, il faudra les valider (commit) ou les annuler (undo) avant de tirer la nouvelle branche.

   • Récupérer la liste de branches distantes à partir du serveur (fetch).
     
     

   • Basculer vers la nouvelle branche en faisant un double clique sur son nom. La branche sera automatiquement tirée.