Les slides de ma session à aux Agile Tour de Rennes, Vannes et Nantes. Ou comment comprendre que faire des tests est vital pour un projet. Mais aussi que ce n'est pas aussi cher qu'on le pense.
Votre projet marche, mais c'est le chaos. Comment arrêter de dépendre de ces "héros" sur qui tout repose ?
Présentation vidéo : https://youtu.be/aClcNdOqtsE
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire
ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la
conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.
[Agile Testing Day] Test Driven Development (TDD)Cellenza
Soyons honnête : nous aimerions tous tester nos plateformes, nos codes, mais personne ne le fait vraiment bien. Heureusement, ce n’est pas une fatalité, et il n’est jamais trop tard pour tester ! La vraie question est : comment tester ? Derrière toute stratégie de tests efficace, il y a une connaissance de tous les types de tests disponibles, de leurs coûts et de leurs utilités. Tout au long de cette journée, nous allons vous détailler les différents types de tests, du test unitaire au test de charge, afin que vous puissiez évaluer la pertinence de chacun dans votre propre contexte.
Les slides de ma session à aux Agile Tour de Rennes, Vannes et Nantes. Ou comment comprendre que faire des tests est vital pour un projet. Mais aussi que ce n'est pas aussi cher qu'on le pense.
Votre projet marche, mais c'est le chaos. Comment arrêter de dépendre de ces "héros" sur qui tout repose ?
Présentation vidéo : https://youtu.be/aClcNdOqtsE
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire
ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la
conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.
[Agile Testing Day] Test Driven Development (TDD)Cellenza
Soyons honnête : nous aimerions tous tester nos plateformes, nos codes, mais personne ne le fait vraiment bien. Heureusement, ce n’est pas une fatalité, et il n’est jamais trop tard pour tester ! La vraie question est : comment tester ? Derrière toute stratégie de tests efficace, il y a une connaissance de tous les types de tests disponibles, de leurs coûts et de leurs utilités. Tout au long de cette journée, nous allons vous détailler les différents types de tests, du test unitaire au test de charge, afin que vous puissiez évaluer la pertinence de chacun dans votre propre contexte.
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
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
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...OCTO Technology
Retrouvez les slides de présentation du petit-déjeuner OCTO du 13 Octobre, axé sur la qualité de code. Présenté et animé par Christophe Thibaut d'OCTO, découvrez le retour d'expérience d'AXA avec Emmanuel Lehmann et Antoine Blancke.
NDepend est un outil populaire d'analyse de code .NET complètement intégré dans VisualStudio. Dans cette session le créateur de NDepend Patrick Smacchia et l'architecte logiciel Bruno Boucard, nous expliqueront sur plusieurs exemples concrets, que peut apporter NDepend à une équipe de développeurs en terme d'agilité, de maintenance et de qualité. Notamment, Patrick montrera comment NDepend est utilisé sur lui-même quotidiennement. Cette session sera l'occasion de mettre en pratique des principes de développements essentiels, efficaces et trop souvent ignorés. Ces principes incluent la programmation par contrat, la couverture de code par les tests-unitaires, les métriques de code et la structuration d'une application par composants.
Speakers : Patrick Smacchia (NDepend), Bruno Boucard (Cellenza)
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 ?
Presentation faite à Agile France en 2011
La revue de code : c’est facile !
Cette présentation est la suite de la session « La revue de code : c’est agile, c’est lean, c’est indispensable ! » présentée à Agile France et Agile Tour en 2010.
Après avoir répondu aux idées reçues sur la revue de code et avoir montré combien une revue de code systématique soutient une démarche agile et lean, cette présentation se focalise sur la mise en place de la revue de code comme étape incontournable du processus de développement.
Nous évoquerons les bonnes pratiques, les difficultés à la mise en place, les pièges à éviter et aussi les outils qui facilitent la revue de code. Une grande partie de la présentation sera dédiée à plusieurs démonstrations, exemples et retours d’expérience.
L'adhésion grandissante à l'approche DevOps est un atout pour l’Agilité et s’impose comme une évolution logique à la transformation Agile. Un des facteurs clés du succès de cette approche est l’automatisation des processus de développement, et donc par le fait même, des tests.
Toutefois, si des tests sont automatisés, ils sont souvent loin des « user stories » qui sont pourtant la cible des Sprints pour livrer la valeur d'affaire. Les équipes prennent généralement en charge l’automatisation des tests unitaires et fonctionnels mais rarement celle des tests intégrés.
Afin de livrer une valeur d’affaire rapidement, il est nécessaire de tester les «user stories », donc d'effectuer des tests de bout-en-bout (end-to-end testing).
Voyez comment adapter vos stratégies de tests automatisé afin de garantir une amélioration continue de la qualité à travers votre organisation.
François Bonetto
AFUP Day 2020 Nantes - Mutation TestingJulien Braure
Slides de ma conférence donnée a l'AFUP Day 2020 Nantes
https://joind.in/event/afup-day-2020-nantes/vos-tests-sont-ils-de-qualite--decouvrez-le-avec-le-mutation-testing
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
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
Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite...OCTO Technology
Retrouvez les slides de présentation du petit-déjeuner OCTO du 13 Octobre, axé sur la qualité de code. Présenté et animé par Christophe Thibaut d'OCTO, découvrez le retour d'expérience d'AXA avec Emmanuel Lehmann et Antoine Blancke.
NDepend est un outil populaire d'analyse de code .NET complètement intégré dans VisualStudio. Dans cette session le créateur de NDepend Patrick Smacchia et l'architecte logiciel Bruno Boucard, nous expliqueront sur plusieurs exemples concrets, que peut apporter NDepend à une équipe de développeurs en terme d'agilité, de maintenance et de qualité. Notamment, Patrick montrera comment NDepend est utilisé sur lui-même quotidiennement. Cette session sera l'occasion de mettre en pratique des principes de développements essentiels, efficaces et trop souvent ignorés. Ces principes incluent la programmation par contrat, la couverture de code par les tests-unitaires, les métriques de code et la structuration d'une application par composants.
Speakers : Patrick Smacchia (NDepend), Bruno Boucard (Cellenza)
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 ?
Presentation faite à Agile France en 2011
La revue de code : c’est facile !
Cette présentation est la suite de la session « La revue de code : c’est agile, c’est lean, c’est indispensable ! » présentée à Agile France et Agile Tour en 2010.
Après avoir répondu aux idées reçues sur la revue de code et avoir montré combien une revue de code systématique soutient une démarche agile et lean, cette présentation se focalise sur la mise en place de la revue de code comme étape incontournable du processus de développement.
Nous évoquerons les bonnes pratiques, les difficultés à la mise en place, les pièges à éviter et aussi les outils qui facilitent la revue de code. Une grande partie de la présentation sera dédiée à plusieurs démonstrations, exemples et retours d’expérience.
L'adhésion grandissante à l'approche DevOps est un atout pour l’Agilité et s’impose comme une évolution logique à la transformation Agile. Un des facteurs clés du succès de cette approche est l’automatisation des processus de développement, et donc par le fait même, des tests.
Toutefois, si des tests sont automatisés, ils sont souvent loin des « user stories » qui sont pourtant la cible des Sprints pour livrer la valeur d'affaire. Les équipes prennent généralement en charge l’automatisation des tests unitaires et fonctionnels mais rarement celle des tests intégrés.
Afin de livrer une valeur d’affaire rapidement, il est nécessaire de tester les «user stories », donc d'effectuer des tests de bout-en-bout (end-to-end testing).
Voyez comment adapter vos stratégies de tests automatisé afin de garantir une amélioration continue de la qualité à travers votre organisation.
François Bonetto
AFUP Day 2020 Nantes - Mutation TestingJulien Braure
Slides de ma conférence donnée a l'AFUP Day 2020 Nantes
https://joind.in/event/afup-day-2020-nantes/vos-tests-sont-ils-de-qualite--decouvrez-le-avec-le-mutation-testing
16. Pourquoi ?
• Tu n’as jamais le temps après
• Tu penses à comment utiliser avant de coder
• Tu implémentes que les tests dont l’on a besoin
• Tu es sûr que le test est faux
• Pas de bug dans le test
• Sûr que tu teste la bonne chose
17. Comment écrire tes tests ?
• Dé
fi
nis un problème simple à résoudre
• S’il passe, tu peux passer à la suite
• Si tu ne peux pas tester
• C’est que tu ne comprends pas le problème
• Tu ne t’y prends surement pas correctement
• Le problème n’est surement pas assez simple
18. Comment améliorer ton code ?
• Écris le code le plus simple possible
• Plus facile à maintenir
• Meilleure couverture de code
• Réusine (refactoring en français) ton code et tu vas
• Améliorer la qualité de ton code
• Être sûr grâce aux tests
• Enlever de la duplication dans ton code (DRY)
• Améliorer la lisibilité et maintenabilité
19. Donc
• Tu écris ton test
• 20 % de ton temps
• 80% du “code”
• Tu écris ton code
• 80 % de ton temps
• 20% du “code”
21. Comment
• Pas sur un vrai projet la première fois
• Commencer par des coding dojo
• Écrire des tests adéquats
• Couverture de code
• Ne pas commenter de tests
• Pair programming
• Garder les tests propres
• Le test ne doit faillir d’une seule manière