Java SE 8 est sûrement la version la plus importante et la plus impactante pour les développeurs. Deux ans après sa sortie, ce talk propose des retours sur les bonnes ou moins bonnes utilisations des principales fonctionnalités de Java 8. Une connaissance de ces fonctionnalités est requise.
Trop souvent tester son code se fait soit en fin de projet, soit pas du tout ; et correspond à une contrainte pour les développeurs. C’est pourtant à la fois un confort et une assurance dans la qualité et de son travail. A travers cette présentation, “tester c’est douter”, j’ai voulu provoquer l’envie de s’y mettre. Expliquer comment les tests amènent à remettre correctement son travail en cause.
Pour ce faire j’ai choisi une approche agnostique, n’évoquant ni les technos ni la manière de les utiliser.
J’ai privilégié de présenter plutôt la logique des tests :
Expliquer ce qu’est un test, les différents types et quand les utiliser.
Evoquer le pattern des tests doubles et différencier un mock d’un stub. Présenter une série de bonnes pratiques pour coder correctement ses tests et éviter les tests smells
Présentation d’un cas pratique pour appuyer la théorie
Présentation des patterns TDD et BDD pour introduire les tests au coeur de ces développements.
Le sujet principal de Java 9 est le support de la modularité mais Java 9 propose aussi de nombreuses autres fonctionnalités. Ce talk a pour but de faire une revue des principales d’entre-elles en attendant la sortie de Java 9 : support de standards, nouvelles API, évolutions dans certaines API, mises à jour des outils du JDK et améliorations de la JVM.
Ce chapitre est destiné pour les étudiants de la 2ème année année master Mathématiques, Cryptologie et Sécurité Informatique (MMCSI) Semestre 3. Il traite les concepts de base du langage Java.
Java SE 8 est sûrement la version la plus importante et la plus impactante pour les développeurs. Deux ans après sa sortie, ce talk propose des retours sur les bonnes ou moins bonnes utilisations des principales fonctionnalités de Java 8. Une connaissance de ces fonctionnalités est requise.
Trop souvent tester son code se fait soit en fin de projet, soit pas du tout ; et correspond à une contrainte pour les développeurs. C’est pourtant à la fois un confort et une assurance dans la qualité et de son travail. A travers cette présentation, “tester c’est douter”, j’ai voulu provoquer l’envie de s’y mettre. Expliquer comment les tests amènent à remettre correctement son travail en cause.
Pour ce faire j’ai choisi une approche agnostique, n’évoquant ni les technos ni la manière de les utiliser.
J’ai privilégié de présenter plutôt la logique des tests :
Expliquer ce qu’est un test, les différents types et quand les utiliser.
Evoquer le pattern des tests doubles et différencier un mock d’un stub. Présenter une série de bonnes pratiques pour coder correctement ses tests et éviter les tests smells
Présentation d’un cas pratique pour appuyer la théorie
Présentation des patterns TDD et BDD pour introduire les tests au coeur de ces développements.
Le sujet principal de Java 9 est le support de la modularité mais Java 9 propose aussi de nombreuses autres fonctionnalités. Ce talk a pour but de faire une revue des principales d’entre-elles en attendant la sortie de Java 9 : support de standards, nouvelles API, évolutions dans certaines API, mises à jour des outils du JDK et améliorations de la JVM.
Ce chapitre est destiné pour les étudiants de la 2ème année année master Mathématiques, Cryptologie et Sécurité Informatique (MMCSI) Semestre 3. Il traite les concepts de base du langage Java.
Les versions de Java se suivent et leurs engouements ne se ressemblent pas : la version 8 de Java est probablement celle qui a suscité le plus d’intérêts chez les développeurs. Java 9, au contraire, est la version de Java qui génère le plus de craintes et d’interrogations voir de peurs. Il faut se préparer pour utiliser Java 9 d’autant que Java 10 est déjà là et les versions suivantes vont s’enchaîner. Le but de ce talk est de parcourir les avantages et les intérêts à utiliser ces nouvelles versions mais aussi certaines difficultés possibles lors de la migration.
Ce n'est pas qu'un slogan politique mais bien la réalité pour Java depuis l'année écoulée.
A tel point que plusieurs caractéristiques historiques de Java sont partiellement remises en cause notamment la lenteur patente entre deux releases, l'embonpoint endémique du JRE/JDK, et même la sacro sainte rétro-compatibilité, ...
Faisons un tour de ces évolutions qui sont parfois de profonds changements avant de fêter le 10ème anniversaire du Nantes JUG.
Les versions de Java se suivent et leurs engouements ne se ressemblent pas : la version 8 de Java est probablement celle qui a suscité le plus d’intérêts chez les développeurs. Java 9, au contraire, est la version de Java qui génère le plus de craintes et d’interrogations voir de peurs. Il faut se préparer pour utiliser Java 9 d’autant que Java 10 est déjà là et les versions suivantes vont s’enchaîner. Le but de ce talk est de parcourir les avantages et les intérêts à utiliser ces nouvelles versions mais aussi certaines difficultés possibles lors de la migration.
A 74-year-old patient with missing teeth and a removable partial denture for 10 years wanted a fixed prosthesis. Clinical examination found root caries on teeth 11, 12, 13, 23, and 25 and existing bridges on teeth 32-43 and 44-47. The treatment plan was to place 4 implants in the upper arch and 2 in the lower arch, followed by fixed prostheses. Temporary bridges were placed. On the day of surgery, extractions and implant placements were done. After 3 months, the implants were loaded with final prostheses.
This document describes an alternative conservative approach to managing extensive tooth surface loss using direct composite restorations rather than traditional indirect restorations like crowns or onlays. The case study involved building up worn teeth on the right side and anterior teeth directly with composite, while allowing teeth on the un-worn left side to supra-erupt over time to make contact. This approach is described as being more conservative, economical, and less stressful than indirect restorations, though it requires more clinical skills and time and restorations may not last as long.
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...Cyrille Grandval
De nos jours de plus en plus d'entreprises ne jurent que par les tests unitaires. Faire du test, faire du test, faire du test ! “Une application n'est pérenne que si elle est testée et elle est testée si plus de 80% du code est couvert.”
Cela devient même un élément décisif du recruteur en entretien :
- Votre collaborateur a l'air vraiment bien mais... Il a déjà fait des tests unitaires ? Il a plus de deux ans d'expérience là dessus ?
- Juste sur deux projets, par contre il possède la bonne philosophie.
- Ah oui mais non il faut qu'il en ait fait 2 ans, c'est un minimum. On cherche des experts nous !
Problématique : "Je veux minimum 80% de couverture de code !!!" Qui n'a pas entendu cette phrase dans la bouche d'un chef de projet ou d'un lead dev trop consciencieux sans doute.
Dans certains projets un test unitaire est bon si il couvre au moins 80% de la fonctionnalité à tester, c'est tout ce qui est demandé et c'est cela qu'il faut avoir. Il est avant tout essentiel de s'interroger sur la notion de couverture de code dans un test unitaire : La couverture de code est-elle un but ? un facteur qualité ? une représentation visuelle d'un test ? Ou est-ce cet horrible fantôme qui vient hanter une application ?
Pour faire simple : un test qui couvre 100% du code à tester est-il forcement fiable ?
Conférence PHPTour Lyon 2014 - Tests unitaires - Je veux mes 80% de couverture de code !!!! http://afup.org/pages/phptourlyon2014/sessions.php#1094
Pourquoi vous ne pouvez pas tester votre codeRémi Lesieur
"Non mais nous, on ne peut pas tester"
Vous avez déjà entendu cette phrase ? Parce que moi, oui, très souvent.
Il y a toujours au moins une bonne raison évoquée. Et si on en parlait ?
Les versions de Java se suivent et leurs engouements ne se ressemblent pas : la version 8 de Java est probablement celle qui a suscité le plus d’intérêts chez les développeurs. Java 9, au contraire, est la version de Java qui génère le plus de craintes et d’interrogations voir de peurs. Il faut se préparer pour utiliser Java 9 d’autant que Java 10 est déjà là et les versions suivantes vont s’enchaîner. Le but de ce talk est de parcourir les avantages et les intérêts à utiliser ces nouvelles versions mais aussi certaines difficultés possibles lors de la migration.
Ce n'est pas qu'un slogan politique mais bien la réalité pour Java depuis l'année écoulée.
A tel point que plusieurs caractéristiques historiques de Java sont partiellement remises en cause notamment la lenteur patente entre deux releases, l'embonpoint endémique du JRE/JDK, et même la sacro sainte rétro-compatibilité, ...
Faisons un tour de ces évolutions qui sont parfois de profonds changements avant de fêter le 10ème anniversaire du Nantes JUG.
Les versions de Java se suivent et leurs engouements ne se ressemblent pas : la version 8 de Java est probablement celle qui a suscité le plus d’intérêts chez les développeurs. Java 9, au contraire, est la version de Java qui génère le plus de craintes et d’interrogations voir de peurs. Il faut se préparer pour utiliser Java 9 d’autant que Java 10 est déjà là et les versions suivantes vont s’enchaîner. Le but de ce talk est de parcourir les avantages et les intérêts à utiliser ces nouvelles versions mais aussi certaines difficultés possibles lors de la migration.
A 74-year-old patient with missing teeth and a removable partial denture for 10 years wanted a fixed prosthesis. Clinical examination found root caries on teeth 11, 12, 13, 23, and 25 and existing bridges on teeth 32-43 and 44-47. The treatment plan was to place 4 implants in the upper arch and 2 in the lower arch, followed by fixed prostheses. Temporary bridges were placed. On the day of surgery, extractions and implant placements were done. After 3 months, the implants were loaded with final prostheses.
This document describes an alternative conservative approach to managing extensive tooth surface loss using direct composite restorations rather than traditional indirect restorations like crowns or onlays. The case study involved building up worn teeth on the right side and anterior teeth directly with composite, while allowing teeth on the un-worn left side to supra-erupt over time to make contact. This approach is described as being more conservative, economical, and less stressful than indirect restorations, though it requires more clinical skills and time and restorations may not last as long.
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...Cyrille Grandval
De nos jours de plus en plus d'entreprises ne jurent que par les tests unitaires. Faire du test, faire du test, faire du test ! “Une application n'est pérenne que si elle est testée et elle est testée si plus de 80% du code est couvert.”
Cela devient même un élément décisif du recruteur en entretien :
- Votre collaborateur a l'air vraiment bien mais... Il a déjà fait des tests unitaires ? Il a plus de deux ans d'expérience là dessus ?
- Juste sur deux projets, par contre il possède la bonne philosophie.
- Ah oui mais non il faut qu'il en ait fait 2 ans, c'est un minimum. On cherche des experts nous !
Problématique : "Je veux minimum 80% de couverture de code !!!" Qui n'a pas entendu cette phrase dans la bouche d'un chef de projet ou d'un lead dev trop consciencieux sans doute.
Dans certains projets un test unitaire est bon si il couvre au moins 80% de la fonctionnalité à tester, c'est tout ce qui est demandé et c'est cela qu'il faut avoir. Il est avant tout essentiel de s'interroger sur la notion de couverture de code dans un test unitaire : La couverture de code est-elle un but ? un facteur qualité ? une représentation visuelle d'un test ? Ou est-ce cet horrible fantôme qui vient hanter une application ?
Pour faire simple : un test qui couvre 100% du code à tester est-il forcement fiable ?
Conférence PHPTour Lyon 2014 - Tests unitaires - Je veux mes 80% de couverture de code !!!! http://afup.org/pages/phptourlyon2014/sessions.php#1094
Pourquoi vous ne pouvez pas tester votre codeRémi Lesieur
"Non mais nous, on ne peut pas tester"
Vous avez déjà entendu cette phrase ? Parce que moi, oui, très souvent.
Il y a toujours au moins une bonne raison évoquée. Et si on en parlait ?
Une conférence de 2h30 (aka université) faites à Devoxx France en 2021 avec Maxime Gellé. On y fait un tour d'horizon des tests logiciels: TDD, Test unitaire vs Test d'integration, l'apport de l'archi hexagonale, Contract testing, property based testing, UI testing ... mais aussi comment "tester en production" !
Dans nos accompagnements techniques, nous observons régulièrement des problèmes de Legacy Code aussi appelé Code Patrimonial. Notamment lorsque des équipes font un virage agile et on leur demande soudainement de faire des tests unitaires automatisés. Pas si facile que cela.
Dans cette présentation, nous verrons les points suivants:
- Description de quelques techniques pour nous aider à tester le Legacy Code
- Comment avoir le droit de travailler sur du code pour le rendre plus facile à travailler
- Quelques pratiques et outils afin de s'en prémunir autant que possible au jour le jour.
Cette présentation a été donnée aux dates suivantes:
- 10 Novembre 2016 - Beer And Learn (Québec)
- 16 Novembre 2016 - Agile Tour Montréal
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...OCTO Technology
par Claude Camus (Coach agile d'organisation @OCTO Technology) et Gilles Masy (Organizational Coach @OCTO Technology)
Les équipes infrastructure, sécurité, production, ou cloud, doivent consacrer du temps à la modernisation de leurs outils (automatisation, cloud, etc) et de leurs pratiques (DevOps, SRE, etc). Dans le même temps, elles doivent répondre à une avalanche croissante de demandes, tout en maintenant un niveau de qualité de service optimal.
Habitué des environnements développeurs, les transformations agiles négligent les particularités des équipes OPS. Lors de ce comptoir, nous vous partagerons notre proposition de valeur de l'agilité@OPS, qui embarquera vos équipes OPS en Classe Business (Agility), et leur fera dire : "nous ne reviendrons pas en arrière".
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO Technology
En cette année 2024 qui s’annonce sous le signe de la complexité, avec :
- L’explosion de la Gen AI
-Un contexte socio-économique sous tensions
- De forts enjeux sur le Sustainable et la régulation IT
- Une archipélisation des lieux de travail post-Covid
Découvrez les Tech trends incontournables pour délivrer vos produits stratégiques.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
2. Kalité de Module
Vous avez dit « Kalité » ?
✗ Tentative de définition
✗ La « Kalité » est une approximation de « Qualité »
✗ Nul ne sait ce que c'est vraiment...
✗ Mais on pense la reconnaître quand on la voit !
✗ C'est avant tout une question de confiance
✗ Construite grâce à la réussite de tests (mais ce n'est pas tout)
✗ Mais absence de bugs (trouvés) n'implique pas Kalité !
✗ Éventuellement si la couverture fonctionnelle des tests est décente
✗ La chasse aux bugs reste cependant ouverte !
✗ Un bug est une différence entre l'attendu et l'implémenté
✗ C'est aussi une différence entre test, documentation & code
✗ Si la documentation est ambiguë, c'est bel et bien un bug !
Journées Perl 2008 – Albi 2 Xavier Caron
4. Kalité de Module
1
Quand & Quoi
✗ Complètement avant
✗ Littérature
✗ CPAN
✗ Articles, conférences, /Perl Mon(k|geur)s/, etc.
✗ « Lis. Apprends. Évolue. » – Klortho le Magnifique
✗ Avant
✗ Générer le squelette du module
✗ Utiliser un système de classes OO comme Moose (si applicable)
✗ Écrire les tests (un soupçon d'XP dans votre code)
✗ Pendant (la phase d'écriture de code)
✗ Documenter au fur et à mesure (et pourquoi pas, avant ?)
✗ Ajouter des tests si nécessaire
Journées Perl 2008 – Albi 4 Xavier Caron
5. Kalité de Module
2
Quand & Quoi
✗ Après (entre codage & livraison)
✗ Tester (suite de tests – acceptation et non-régression)
✗ Mesurer la couverture de POD
✗ Mesurer la couverture de code des tests
✗ Mesurer la couverture fonctionnelle des tests (Ah ! Ah !)
✗ Générer des synthèses lisibles
✗ Pour avoir un statut en un coup d'œil et une meilleure traçabilité
✗ Bien après (la livraison)
✗ Reformuler tôt, reformuler souvent
✗ La suite de tests (non-régression) devrait assurer que rien n'a été cassé
✗ Suite à un rapport de bug...
✗ Ajouter tout d'abord des tests afin de reproduire le problème
✗ Puis seulement éradiquer le(s) bug(s)
✗ Tester de nouveau (suite de tests – non-régression)
Journées Perl 2008 – Albi 5 Xavier Caron
6. Kalité de Module
L'Enfer, c'est les autres…
✗ … codeurs
✗ « Codez comme si le gars devant reprendre votre code était un
psychopathe violent qui sait où vous habitez. » – D. Conway
✗ Préface du SICP
✗ « Les programmes doivent être écrits afin d'être lus par des
humains et incidemment exécutés par des machines. »
Journées Perl 2008 – Albi 6 Xavier Caron
7. Kalité de Module
1
Les pré-requis
✗ SCM – gestion de code source (~ historique + //)
✗ Par exemple : cvs, subversion, svk, darcs, git, etc.
✗ Attention ! Requiert une certaine étiquette (labels, branches, etc.)
✗ Utiliser une « machine à différence » (diff), avec GUI (tkdiff)
✗ RT – gestion de tickets (~ intention)
✗ Par exemple : cvstrac, trac, RT, bugzilla, etc.
✗ Éditeur avec coloration syntaxique
✗ Par exemple : NEdit, vi, emacs, etc.
✗ Des règles de codage consistantes
✗ Voire même les « bonnes » ;)
✗ Cf PBP (livre) + Perl::Critic (module) + perltidy (outil)
Journées Perl 2008 – Albi 7 Xavier Caron
8. Kalité de Module
2
Les pré-requis
✗ On peut même utiliser un IDE
✗ Comme Eclipse + plugin Perl
✗ On ne choisit pas forcément...
✗ SCM, RT, « bonnes » pratiques ou même l'éditeur de texte :(
✗ Fonction de l'OS, des choix « corporate », du client, etc.
✗ Faute d'avoir ce que l'on aime, il faut aimer ce que l'on a !
✗ Mais on choisit d'utiliser les directives « use »
✗ use strict; # code
use warnings; # test
✗ C'est même très fortement conseillé !
✗ Sinon : « Il y en a qui ont essayé... »
Journées Perl 2008 – Albi 8 Xavier Caron
9. Kalité de Module
3
Les pré-requis
✗ « Ils ont eu des problèmes ! »
Journées Perl 2008 – Albi 9 Xavier Caron
10. Kalité de Module
1
Ne pas réinventer la roue
✗ Éviter de commettre les erreurs des autres
✗ Difficile de résister au syndrome NIH (« Not Invented Here »)
✗ Moins d'orgueil, plus de paresse !
✗ Chercher plutôt à utiliser un module du CPAN
✗ « Je code en CPAN, le reste c'est de la syntaxe » – Audrey Tang
✗ Mais faire au préalable une revue de module
✗ Utilité dans la pratique
✗ Possibilités de configuration
✗ Développement actif du module (mais peut-être déjà stable)
✗ Mais si vous voulez toujours réinventer la roue…
✗ Au moins essayez d'en réinventer une meilleure !
Journées Perl 2008 – Albi 10 Xavier Caron
11. Kalité de Module
2
Ne pas réinventer la roue
✗ Quelques tâches parmi tant d'autres...
✗ Des fois même pénibles à coder !
✗ Analyser la ligne de commande
✗ Getopt::Long (un grand classique)
✗ Pod::Usage
✗ Gérer des configurations
✗ Config::Std (~ M$ INI)
✗ YAML
✗ Et non, pas de XML (« même pas dans tes rêves les plus fous ») !
✗ Pèle-mêle... (cf Phalanx Top 100)
✗ HTML::Parser, XML::Twig, Spreadsheet::ParseExcel,
Parse::RecDescent, RegExp::Common, List::MoreUtils, etc.
Journées Perl 2008 – Albi 11 Xavier Caron
12. Kalité de Module
3
Ne pas réinventer la roue
✗ Littérature
✗ Perl en action (Perl cookbook – Christiansen & Torkington)
✗ De l'art de programmer en Perl (Perl best practices – Conway)
✗ Mastering algorithms with Perl (Orwant, Hietaniemi & MacDonald)
✗ Perl testing: a developer's handbook (Ian Langworth & Chromatic)
✗ The pragmatic programmer (Hunt & Thomas)
✗ Lessons learned in software testing (Kaner, Bach & Pettichord)
✗ The art of agile development (Shore & Warden)
✗ Expériences
✗ Groupes (Mongueurs de Perl, Perl Mongers, Perl Monks)
✗ Conférences (Journées Perl, Perl Workshops, YAPC)
✗ Articles (Mongueurs de Perl / GLMF, perl.com)
Journées Perl 2008 – Albi 12 Xavier Caron
13. Kalité de Module
Le triptyque du programmeur
Orgueil
POD Paresse
TESTS
CODE
Impatience
Journées Perl 2008 – Albi 13 Xavier Caron
14. Kalité de Module
Au commencement...
✗ Bien construire son propre module
✗ Un module Perl est une arborescence très précise
✗ Facile d'oublier l'un de ses nombreux fichiers
✗ Difficile de se souvenir de la syntaxe de chacun d'entre-eux
✗ Utiliser un module dédié du CPAN
✗ Par exemple : Module::Starter (voire même Module::Starter::PBP)
✗ Crée des « gabarits » à compléter
✗ Certains tests vérifieront qu'ils ont bien été modifiés
✗ Cf l'article de Sébastien Aperghis-Tramoni
✗ « Créer une distribution pour le CPAN », GLMF #69
✗ http://articles.mongueurs.net/magazines/linuxmag69.html
Journées Perl 2008 – Albi 14 Xavier Caron
15. Kalité de Module
1
Le test pour les nuls
✗ Tester = confronter intention & implémentation
✗ À l'aide de techniques (tests directifs ou aléatoires contraints)
✗ Et d'un modèle de référence (OK ~ pas de ≠ avec ce dernier)
✗ Intention
✗ Cristallisée dans une spécification, un plan de test, etc.
✗ Quand lesdits documents sont bel et bien disponibles !
✗ Documents non-formels car destinés à une lecture humaine
✗ Donc bien évidemment sujets à interprétation
✗ Implémentation
✗ Code (+ documentation)
✗ Décomposé en unités de base (modules = ∑ fonctions)
Journées Perl 2008 – Albi 15 Xavier Caron
16. Kalité de Module
2
Le test pour les nuls
✗ Développement piloté par les tests (TDD)
✗ Tests unitaires (au standard xUnit ou non)
✗ Tests d'acceptation (ou de recette – ce pour quoi le client a payé)
✗ Suite de tests ≈ spécification exécutable
✗ C'est déjà un peu plus formel (ou moins informel ;)
✗ « Les vieux tests ne meurent jamais, ils deviennent des tests de
non-régression ! » – Chromatic & Michael G Schwern
✗ Mais un test réussi ne révèle pas grand chose !
✗ Ça doit même devenir frustrant pour le testeur !
✗ Juste histoire d'enfoncer le clou...
✗ « Tester un programme démontre la présence de bugs, pas leur
absence. » – Edsger Dijkstra
Journées Perl 2008 – Albi 16 Xavier Caron
17. Kalité de Module
3
Le test pour les nuls
✗ Un ingénieur de test doit se poser 2 questions
✗ « Est-ce correct ? »
✗ « Ai-je fini ? »
✗ Est-ce correct ?
✗ Tous les tests de la suite sont-ils OK ?
✗ C'est le rôle du protocole TAP et de Test::More + Test::Harness
✗ Avec les notions de SKIP/TODO, c'est plutôt binaire (i.e., 100%)
✗ Ai-je fini ?
✗ Mes tests ont-ils exercé toutes mes lignes de code ?
✗ Notion de couverture de code (associée à une métrique)
✗ C'est le domaine du module Devel::Cover
✗ Mais... mes lignes de code implémentent-elles la fonctionnalité ?
Journées Perl 2008 – Albi 17 Xavier Caron
18. Kalité de Module
4
Le test pour les nuls
✗ Couverture de code ≠ couverture fonctionnelle
✗ C'est en effet très tentant de confondre les deux
✗ Couverture de code
✗ On peut couvrir le code à 100% mais...
✗ Il peut manquer en fait celui réalisant la fonctionnalité demandée !
✗ Couverture fonctionnelle
✗ Meilleure définition du « ai-je fini ? » en ces termes
✗ Liée aux combinaisons possibles en entrée d'une fonction (cf CRT)
✗ M'enfin ! Comment mesurer la CF en Perl ?
✗ C'est possible avec des HDVL comme SystemVerilog
✗ C'est dans les TODO du module Test::LectroTest
Journées Perl 2008 – Albi 18 Xavier Caron
19. Kalité de Module
5
Le test pour les nuls
✗ Couverture de code ≠ couverture fonctionnelle
✗ Le trivial contre-exemple suivant
✗ =head2 foo
Retourne 'foo' à 'bar' et 'gabuzomeu' à 'baz'. Retourne undef si entrée inconnue.
=cut
sub foo {
my $s = shift;
return 'gabuzomeu' if $s eq 'baz';
undef;
}
use Test::More tests => 2;
is ( foo( 'baz' ), 'gabuzomeu', "retourne 'gabuzomeu' à baz" );
is ( foo( 'foo' ), undef, "retourne undef si entrée inconnue" );
✗ Atteint 100% de CC... mais n'implémente pas foo ( 'bar' ) = 'foo' !
✗ ---------------------------- ------ ------ ------ ------ ------ ------ ------
File stmt bran cond sub pod time total
---------------------------- ------ ------ ------ ------ ------ ------ ------
t_foo.t 100.0 100.0 n/a 100.0 n/a 100.0 100.0
Total 100.0 100.0 n/a 100.0 n/a 100.0 100.0
---------------------------- ------ ------ ------ ------ ------ ------ ------
Journées Perl 2008 – Albi 19 Xavier Caron
20. Kalité de Module
Tests unitaires
use warnings; use strict;
use Test::More; package Foo; lib/Foo.pm
use Carp::Assert::More;
plan(tests=>N);
# ...
use_ok('Foo');
=head2 bar
# ... bar ( baz )
Test::More
is_deeply( Rince baz. is(), is_deeply(), ...
bar ($baz), =cut
refbar ($baz),
'baz au bar' sub bar {
); stimulus my $baz = shift; ≈ TAP:
assert_nonblank $baz; OK, !OK
# ... # ... SKIP /
} ƒ()
TODO
t/13-bar.t # ... modèle de référence
Journées Perl 2008 – Albi 20 Xavier Caron
21. Kalité de Module
1
Programme de test type
✗ Le plus simple possible
✗ « Quis custodiet ipsos custodes ? »
✗ Sinon il devient nécessaire de tester / factoriser le code de test
✗ En fait, souvent une boucle
✗ Itérations sur des cas d'utilisations (« use cases »)
✗ Comparaison sortie effective / résultat attendu
✗ La fonction de différence varie en fonction du type de données
✗ Pour ce qui est de l'attendu
✗ Structure complexe sérialisée (Data::Dumper::Simple)
✗ Format dédié (XML, JSON, etc.) mais attention à la différence !
✗ Résultat d'une fonction de référence (ré-écriture complète)
✗ Structure complexe codée en dur (liste/hash/Tie::IxHash)
Journées Perl 2008 – Albi 21 Xavier Caron
22. Kalité de Module
2
Programme de test type
✗ use warnings; # fortement conseillé
use SpecifyParser;
Module
CPAN use Test::More;
Dumps my @pl_files = glob "*/*.pl"; # sérialisés avec Data::Dumper::Simple
+ Plan
plan ( tests => scalar @pl_files ); # plan de test
my $parser = SpecifyParser->new;
my $checks;
Boucle
+ Stimuli for my $pl_file ( @pl_files ) {
( my $v_file = $pl_file ) =~ s/.pl$/.v/;
do $pl_file; # désérialise $checks
Compare
is_deeply ( [ $parser->parse_file ( $v_file ) ], $checks, $pl_file );
}
Journées Perl 2008 – Albi 22 Xavier Caron
23. Kalité de Module
1
Le protocole TAP
✗ « Test Anything Protocol »
✗ Séparation des tests de l'interpréteur de résultats
✗ Développé par des perlistes mais en fait indépendant du langage
✗ La fonctionnalité à tester est une boîte noire
✗ Le programme de test doit juste fournir un flux TAP
✗ A l'aide d'une boîte à outils (un module du CPAN bien sûr)
✗ Par exemple le module Test::More (plan(), use_ok(), is(), etc.)
✗ Le nombre de tests est annoncé à l'avance
✗ Notion de « plan » de test (léger AMHA, vs IEEE Std 829 + lourd)
✗ Le test est déclaré faux si M tests reportés ≠ N tests annoncés
✗ Car un test peut par exemple tout planter avant la fin des tests
Journées Perl 2008 – Albi 23 Xavier Caron
24. Kalité de Module
2
Le protocole TAP
✗ Le plan de test
✗ 1..N (todo X Y)?
✗ Les tests
✗ ok X - description
✗ not ok X - description
✗ ok Y # SKIP raison
✗ not ok Y # TODO raison
✗ SKIP
✗ Éluder le test à cause d'un facteur externe (module !, OS, etc.)
✗ TODO
✗ Fonctionnalité pas encore implémentée (peut néanmoins être OK)
Journées Perl 2008 – Albi 24 Xavier Caron
25. Kalité de Module
3
Le protocole TAP
✗ Cf articles GLMF #88 & #89
✗ « Les tests en Perl - Présentation et modules standards » &
« Tests et Perl - Bonnes pratiques »
– Sébastien Aperghis-Tramoni & Philippe Blayo
✗ Quelques interpréteurs TAP
✗ Test::Harness
✗ Test::TAP::Model (MI bâti sur le flux TAP Test::TAP::HTMLMatrix)
✗ Pour en savoir plus...
✗ La spécification est en fait le module TAP
✗ Article sur Wikipedia : Test_Anything_Protocol
✗ Présentation de Philippe aux Journées Perl (juste après !)
✗ Site web : http://testanything.org/
✗
Journées Perl 2008 – Albi La présentation Test::Tutorial 25
(chromatic & Michael G Schwern) Xavier Caron
27. Kalité de Module
1
Matrice TAP
✗ Offre une vue synthétique de la suite de tests
✗ Très appréciable car le nombre de tests ne peut qu'augmenter
✗ À l'aide d'un interpréteur dédié
✗ Le module Test::TAP::Model::Visual
✗ L'interpréteur analyse le flux TAP et construit un MI TTM
✗ Le MI TTM est transformé en HTML (Test::TAP::HTMLMatrix)
✗ Très simplement
✗ use Test::TAP::Model::Visual;
use Test::TAP::HTMLMatrix;
$ttm = Test::TAP::Model::Visual->new_with_tests( <t/*.t> );
$v = Test::TAP::HTMLMatrix->new( $ttm );
open FH, "> matrice.html";
print FH $v->html;
Journées Perl 2008 – Albi 27 Xavier Caron
28. Kalité de Module
2
Matrice TAP
✗ Notre make test de tout à l'heure
Journées Perl 2008 – Albi 28 Xavier Caron
29. Kalité de Module
3
Matrice TAP
✗ Autre exemple : transformation de données
Journées Perl 2008 – Albi 29 Xavier Caron
30. Kalité de Module
1
Couverture de code
✗ Charger le module Devel::Cover lors du test
✗ % cover -delete
% HARNESS_PERL_SWITCHES=-MDevel::Cover make test
% cover -report html
Journées Perl 2008 – Albi 30 Xavier Caron
31. Kalité de Module
2
Couverture de code
✗ Statements
✗ Toutes les instructions ont-elles été exécutées ?
✗ Branches
✗ Vérifie les alternatives des branchements conditionnels (if, ?:)
✗ Conditions
✗ Vérifie les différentes possibilités dans les expressions logiques
✗ Subroutines
✗ Toutes les fonctions ont-elles été appelées ?
✗ POD
✗ Utilisation du module POD::Coverage
Journées Perl 2008 – Albi 31 Xavier Caron
32. Kalité de Module
Documentation
✗ Du code testé et couvert, c'est déjà pas mal
✗ Du code documenté, c'est mieux !
✗ Documentation écrite en POD (« Plain Old Doc »)
✗ Il faut en vérifier la syntaxe à l'aide du module Test::POD
✗ C'est le rôle du test t/pod.t (créé par Module::Starter)
✗ Couverture de POD
✗ Tâche assumée par le module Test::POD::Coverage
✗ Vérifie que toute fonction possède une documentation associée
✗ En pratique, vérifie
✗ =item foo ... =cut
✗ =head foo ... =cut
✗ C'est le rôle du test t/pod-coverage.t (créé par Module::Starter)
Journées Perl 2008 – Albi 32 Xavier Caron
33. Kalité de Module
Kwalitee
✗ Pour une définition plus exhaustive : CPANTS
✗ « CPAN Testing Service » – http://cpants.perl.org/kwalitee.html
✗ Définit des indicateurs de Kalité (« ALPHA – Hic sunt dracones! »)
✗ Obtenir les indicateurs : le module Test::Kwalitee
✗ Ajouter le test t/kwalitee.t à la suite de tests :
✗ eval { require Test::Kwalitee };
exit if $@;
Test::Kwalitee->import;
✗ ok 1 - extractable
ok 2 - has_readme
ok 3 - has_manifest
ok 4 - has_meta_yml
ok 5 - has_buildtool
ok 6 - has_changelog
ok 7 - no_symlinks
ok 8 - has_tests
ok 9 - proper_libs
ok 10 - no_pod_errors
ok 11 - use_strict
ok 12 – has_test_pod
ok 13 - has_test_pod_coverage
Journées Perl 2008 – Albi 33 Xavier Caron
34. Kalité de Module
Assertions
✗ Décrivent les hypothèses de travail d'une fonction
✗ Ses limites, ce qu'elle ne sait pas faire « du tout du tout » !
✗ Il vaut mieux planter le programme dès que possible
✗ Plutôt que de le laisser s'embarquer vers l'imprévisible
✗ Un plantage à cause d'une assertion est plus facile à résoudre
✗ « Les programmes morts ne racontent pas de craques ! »
– Hunt & Thomas in The Pragmatic Programmer
✗ Assertions du module Carp::Assert::More
✗ Simples assert_ + (is, isnt, like, defined, nonblank)
✗ Numériques assert_ + (integer, nonzero, positive, ...)
✗ Références assert_ + (isa, nonempty, nonref, hashref, listref)
✗ Array/hash assert_ + (in, exists, lacks)
Journées Perl 2008 – Albi 34 Xavier Caron
35. Kalité de Module
1
Test::LectroTest
✗ Les tests traditionnels sont dits « dirigés »
✗ Séquences de stimuli et de comparaisons à des valeurs attendues
✗ Mais on ne pense pas forcément à tout (# de combinaisons)
✗ Une alternative : des tests aléatoires contraints
✗ Ou en Anglais, CRT : « Constrained Random Testing »
✗ On laisse la machine faire le sale boulot, (pseudo-)aléatoirement
✗ La recette avec Test::LectroTest
✗ Associer un type à chacun des paramètres (des types en Perl ?)
✗ Ajouter des contraintes aux paramètres (~ sous-ensembles)
✗ Faire N itérations, mesurer la CF, bidouiller les contraintes, goto 0
✗ Pas encore utilisé en production
✗
Journées Perl 2008 – Albi
Son alter-ego dans le monde 35
matériel l'est (codé en SystemVerilog) Caron
Xavier
36. Kalité de Module
2
Test::LectroTest
✗ Le code suivant
✗ use Test::LectroTest::Compat; # ::Compat permet d'interfacer Test::More
use Test::More tests => 1;
sub ref_foo {
{ bar => 'foo', baz => 'gabuzomeu' }->{shift()}; Modèle de référence
}
my $property = Property {
##[ s <- Elements( 'foo', 'bar', 'baz' ) ]## Contraintes sur les entrées
is( foo( $s ), ref_foo( $s ), 'foo / ref_foo' ); Comparaison à la référence
}, name => 'toutes les entrées possibles de foo' ;
holds( $property, trials => 100 ); # vérifie que la propriété "tient" sur 100 entrées aléatoires
✗ Prouve que foo ( 'bar' ) ≠ 'foo'
✗ # Failed test 'property 'toutes les entrées possibles de foo' falsified in 4 attempts'
# in lt_foo.t at line 30.
# got: undef
# expected: 'foo'
# Counterexample:
# $s = "bar";
✗ CF ≈ statistiques sur les ≠ valeurs des entrées
Journées Perl 2008 – Albi 36 Xavier Caron
37. Kalité de Module
Reformuler
✗ Reformuler tôt, reformuler souvent
✗ Pour combattre sans relâche l'entropie toujours grandissante
✗ À cause de : résolution de bugs, nouvelles fonctions ou « ruses »
✗ La suite de tests devrait assurer le respect de l'intégrité (cf C.F.)
✗ Seulement sur une branche de développement !
✗ On ne touche pas à une branche de production, sauf bug avéré
✗ Ni rajouter de fonctions, ni résoudre des bugs !
✗ Seulement rendre le code plus concis/lisible/testable… élégant !
✗ « La simplicité est le pré-requis de la lisibilité » – EWD498
✗ Progresser par petits incréments (plus facile à tracer/défaire)
✗ Pour en savoir plus…
✗
Journées Perl 2008 – Albi
Présentation de Michael G Schwern : “Tales Of Refactoring!”
37 Xavier Caron
38. Kalité de Module
En résumé...
✗ A priori
✗ Lire, apprendre et poser des questions (puis « évoluer » )
✗ Utiliser des outils éprouvés (SCM, RT, éditeurs, etc.)
✗ Avoir de « bonnes » pratiques (i.e., consistantes)
✗ Ne pas réinventer la roue
✗ Écrire les tests (voire même la documentation) en premier
✗ A posteriori
✗ Utiliser le protocole de test TAP et ses interpréteurs associés
✗ Analyser les taux de couverture de code (≠ CF !) et de POD
✗ Insérer des assertions dans le code
✗ Voire même laisser la machine faire le sale boulot à votre place !
✗ Générer des rapports de test synthétiques et lisibles
Journées Perl 2008 – Albi 38 Xavier Caron
39. Kalité de Module
Ingénierie sociale
✗ Comme dans beaucoup d'activités humaines
✗ Il y a la technique et il y a l'engagement
✗ La technique
✗ On vient d'en parler pendant 40 (longues, non ?) minutes
✗ Et c'était loin d'être exhaustif !
✗ L'engagement
✗ Sans la motivation, point de Kalité !
✗ C'est un chemin (à suivre) et non pas une destination (à atteindre)
✗ Une dernière citation pour conclure
✗ « À cette époque (1909), l'ingénieur en chef était aussi presque
toujours le pilote d'essai. Cela eu comme conséquence heureuse
d'éliminer très rapidement les mauvais ingénieurs dans l'aviation. »
Journées Perl 2008 – Albi
– Igor Sikorsky 39 Xavier Caron