Please enable JavaScript.

Coggle requires JavaScript to display documents.

Culture code - Coggle Diagram

- - - - utiliser des checklists
      - Statut sur le défaut : Accepté ou refusé ?
      - Suivi des défauts trouvés
      - Avoir des standards écrits et partagés.
  - - - Distinguer d’une part des tests métier qui servent à valider les fonctionnalités du produit v.s. des tests techniques (le fonctionnement d’unités de code (tests unitaires), mais aussi la sécurité et la performance)
      - On différencie également ces tests selon qu’ils sont utilisés pour contrôler le logiciel ou pour guider sa construction
      - Les tests exploratoires visent à être les plus exhaustifs et les plus imaginatifs possible pour que les défauts soient détectés avant la mise en production.
      - Les tests d’acceptation utilisateur visent, comme leur nom l’indique, à faire valider le produit par des utilisateurs, tandis que les tests d’usabilité permettent de s’assurer du niveau de l’expérience utilisateur.
      - Tester pour construire
        
        Les tests de construction soutiennent et guident l’équipe dans les différentes étapes de la création du logiciel.
        
        Tests fonctionnels (les cas de tests sont rédigés avant les dév). Les User Stories, celles-ci sont accompagnées de critères d’acceptation ainsi que d’exemples concrets qui serviront de scénarios de test (Behavior Driven Dev. BDD)
        
        Tests unitaires et tests d’intégration
        
        On y inclut des tests unitaires et des tests d’intégration
        , qui seront toujours automatisés. L'objectif est de vérifier l’assemblage.
        
        l’échafaudage entourant la construction devient alors progressivement une assurance, un harnais de tests garantissant la non régression
      - Où mettre l’énergie ?
        
        Tester devient une pratique centrale de l’équipe. IL existe la méthode des 3 amigos. BDD doit avant tout reposer sur l’échange et des exemples concrets, sans lesquels les tests fonctionnels automatisés n’auront que peu de valeur ajoutée.
        
        l’objectif de parvenir dès que possible à un squelette opérationnel d’application, testé automatiquement (outside in test driven Development)
        
        Il faut automatiser les tests rapides à exécuter avec des logiciels efficaces en termes de détection et de correction d’anomalie, peu coûteux à automatiser et à maintenir.
        
        Solutions d'outils (xUnit, Cucumber, Selenium)
        
        Il est donc judicieux de mettre l’accent sur les tests unitaires automatisés. il est donc préférable de concentrer l’effort d’automatisation sur les tests de construction.
  - - - Commencez toujours par un test automatisé qui échoue.
        
        • N’ajoutez jamais de tests si un test échoue déjà. • Éliminez toute duplication.
        
        • Soignez la qualité du code de test autant que le code de l’implémentatio
    - - Fake it until you make it
      - Reflechir avant d'agir
      - Pour guider son travail en TDD, le développeur peut dresser la liste des comportements auxquels devra répondre la fonction
      - TESTS FIRST
        
        First : le test est écrit en premier
        
        Independent : le test s’exécute indépendamment des autres
        
        Repeatable : le test produit le même résultat à chaque appel
        
        Simple : le test met en œuvre le minimum de données
        
        self-Testing : le test est automatisé
      - L'importance des suites de test
        
        ils sont une spécification technique détaillée, automatisée et exécutable, à l’usage des futurs développeurs ayant à faire évoluer le produit
      - Les freins à l'adoption de la méthode
        
        La nécessité de se former
        
        C’est l’adoption de la méthode qui provoque une diminution temporaire de l’efficacité de l’équipe de développement, et non son usage au quotidien.
        
        Il n’y a en réalité qu’une seule et unique manière d’intégrer TDD dans notre manière de développer : par la pratique.
        
        L’apprentissage de TDD demande de la rigueur et un renversement du mode de pensée habituel.
        
        Les difficultés avec du code legacy
        
        Poser le premier test fera apparaître les problèmes de design : dépendances statiques, effets de bords imprévus, couplage fort, etc.
        
        La prédominance des habitudes
        
        Méthodes pour contrer les freins à l'adoption
        
        Le travail en pair programming.
        
        Cet exercice permet à tour de rôle de s’astreindre à uniquement ré échir au test, à l’intention du code, tout en sachant que l’implémentation sera écrite par son binôme
    - - impact positif sur la productivité : le feedback
        rapide et fréquent qu’elle offre permet au développeur de maintenir sa concentration et
        de garder le fil de sa pensée
        
        A cause du refactoring, le code a une tendance naturelle à devenir plus lisible et plus propre
        
        Réduction conséquente du temps passé à tester en recette et à corriger les défaut
      - La nature itérative de TDD pousse le développeur à se poser des questions sur les comportements que doit offrir la fonction testée
- - - - alimenter une dynamique d’apprentissage permanente
      - créer un cadre qui permet à chacun de progresser tout en s’assurant que l’on respecte les enjeux de réalisation du prod.
        
        faciliter l’apprentissage des pratiques de développement
        
        favoriser des moments d’apprentissage dédiés Dojo/formations etc...
        
        Exemplarité
        
        Faire de la veille
    - - Timeboxer la résolution de problème
      - laisser la place à l’échec, tout en créant un cadre propice à l’apprentissage.