Les tests unitaires font maintenant partie de nos pratiques courantes de développement d'applications. Par contre, ils sont encore trop souvent considérés comme du code de second ordre, écrit rapidement après le développement sans trop d'attention. Considérant qu'un bon test unitaire doit être facile à comprendre, rapide, indépendant et ne tester qu'une seule chose alors comment faire pour améliorer la situation?
Avec l'arrivée des Single Page Applications avec du code côté client de plus en plus complexe il est grand temps de commencer à penser à bien tester notre code JavaScript. Aujourd'hui il existe déjà plusieurs façons d'écrire des tests côté client mais ça peut paraître encore très compliqué.
Dans cette présentation je vais montrer une solution simple et qui marche bien pour mes projets web: Node.js comme runtime, npm comme package manager, gulp comme task runner, jasmine comme librairie de test ainsi que le Task Runner Explorer de Visual Studio.
[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.
[Agile Testing Day] Behavior Driven Development (BDD)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.
Tester avant de déployer ; comment tester ses déploiements ARM.AZUG FR
Lorsque l’on parle d’infrastructure as Code, on imagine qu’écrire des fichiers JSON représentant une infrastructure est la seule étape. Pourtant il est nécessaire de pouvoir appliquer les mêmes principes de test que l’on trouve dans le développement logiciel à ce que l’on doit déployer sur Azure. Dans cette session nous découvrirons comment effectuer des tests sur les templates ARM et comment interpréter les résultats. Nous nous intéresserons à ARM Template Toolkit (arm-ttk) présenter à MS Ignite 19 et comment l’utiliser et l’étendre pour améliorer la qualité du code et du travail d’équipe. Pour finir nous regardons la façon d’intégrer cela dans une chaine de déploiement.
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
Avec l'arrivée des Single Page Applications avec du code côté client de plus en plus complexe il est grand temps de commencer à penser à bien tester notre code JavaScript. Aujourd'hui il existe déjà plusieurs façons d'écrire des tests côté client mais ça peut paraître encore très compliqué.
Dans cette présentation je vais montrer une solution simple et qui marche bien pour mes projets web: Node.js comme runtime, npm comme package manager, gulp comme task runner, jasmine comme librairie de test ainsi que le Task Runner Explorer de Visual Studio.
[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.
[Agile Testing Day] Behavior Driven Development (BDD)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.
Tester avant de déployer ; comment tester ses déploiements ARM.AZUG FR
Lorsque l’on parle d’infrastructure as Code, on imagine qu’écrire des fichiers JSON représentant une infrastructure est la seule étape. Pourtant il est nécessaire de pouvoir appliquer les mêmes principes de test que l’on trouve dans le développement logiciel à ce que l’on doit déployer sur Azure. Dans cette session nous découvrirons comment effectuer des tests sur les templates ARM et comment interpréter les résultats. Nous nous intéresserons à ARM Template Toolkit (arm-ttk) présenter à MS Ignite 19 et comment l’utiliser et l’étendre pour améliorer la qualité du code et du travail d’équipe. Pour finir nous regardons la façon d’intégrer cela dans une chaine de déploiement.
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
Outils et pratiques : tester une application web modernehalleck45
Introduction aux pratiques de testabilité logicielle : types de tests, outils. Présentation aux Rencontres Mondiales du Logiciel Libre 2014.
Vidéo : http://video.rmll.info/videos/tester-une-application-web-quels-outils-et-quelles-pratiques/
[Agile Testing Day] Techniques avancées de testsCellenza
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.
Au cours des derniers mois, j'ai rédigé plus de 600 tests unitaires (Peut-être plus, j'ai perdu le compte). Grâce à cette présentation, vous pourrez éviter de devenir aussi cinglé que moi en bénéficiant de mon expérience, alors que je vous expliquerais comment rédiger des tests avec les Fakes de Microsoft (autrefois appelés Moles), les obstacles à éviter, des trucs pour sauver du temps lors de la rédaction de tests, et à quelle déité païenne vous devez faire des sacrifices pour que tout fonctionne. À moins que je me sois trompé de livre...
Conférencier: Frédéric Simard
Il s'agit d'une initiation a l'utilisation des tests unitaires
La formation présentera les éléments suivants :
•Qu’est ce qu’un test ?
•Définition
•Quelques règles
•Avantage et intérêt
•Outil de test
•Cas à tester
•Les résultats
•Test Driven Development
•Mock
•Convention nommage
•Utilisation Junit
•Conclusion
Cette formation est proposée par ISEN Dev, un projet associatif étudiant de l'association Isen Engineering.
Elle est réalisé en 2013 par SAEZ Jonathan
Le Test Driven Infrastructure, c'est un peu le TDD pour les projets DevOps. Il va vous permettre de tester votre infrastructure unitairement, de bout en bout et à chaque changement.
Industrialiser le contrat dans un projet PHPhalleck45
La notion de contrat intervient à tous les étages en PHP : du code source au besoin fonctionnel, en passant par la nécessité de travailler en équipe ou de fournir un travail clair et compréhensible. Petit tour d'horizon des outils qui vous permettront de vous assurer automatiquement que ces contrats sont bien respectés.
Conférences lors du rendez-vous AFUP Nantes du 29 octobre 2012
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 ?
Le test, qu'il soit unitaire ou fonctionnel, est à la mode dans le monde du développement logiciel, suite entre autre à la mise en œuvre croissante des méthodes agiles et notamment de l'intégration continue ou des méthodes de développement telles que le TDD, le BDD ou la programmation par contrat. Récemment, ce phénomène a encore été amplifié au sein de la communauté PHP par l'apparition aux côtés de l'incontournable PHPUnit d'outils plus originaux tels que Behat, Praspel ou atoum qui permettent au développeur de rédiger des tests plus simplement. Pourtant, nous constatons tous les jours que le test conserve une grande part de mystère pour la plupart des développeurs, Bien souvent, ces derniers ne savent pas quoi tester, et encore moins comment écrire un test efficace ou mettre en place une politique de test pertinente. Certains s'interrogent par exemple sur la pertinence de leurs tests, se demandent s'il faut absolument tout tester, d'autres s'il est possible de tester la création d'un fichier, voir même s'il est intéressant de le faire, tandis que d'autres se demandent où se situe la frontière entre le test unitaire et le test fonctionnel ou s'il est nécessaire de tester toutes les méthodes d'une classe, alors que d'autres encore ne savent tout simplement pas par où commencer. Durant cette conférence, nous allons tenter, à l'aide de nos expériences respectives de créateur de framework de tests et de doctorat en informatique spécialisé dans le test, de répondre aux questions récurrentes que se pose une personne confrontée à la mise en place d'une politique de qualité logicielle en général et à l'écriture d'un test logiciel en particulier. À l'issue de cette foire aux questions didactique et interactive, vous devriez être capable d'aborder le test, indépendamment de sa nature, de manière plus sereine et efficace et produire ainsi un logiciel de la qualité que vous désirez.
Vous avez dit Selenium ? L'outil qui permet d'automatiser les tests fonctionnels ? Multi-langage ? Multi-plateforme ? Et vraiment intéressant pour garantir la qualité de votre projet tout au long de sa réalisation ?
Oui, il s'agit bien de l'outil multi-tâches que l'on gagne à connaître dans un monde Agile où la qualité de votre application ne peut pas être négligée.
Mais jusqu'à quel niveau avez-vous utilisé l'outil ? Avez-vous industrialisé durablement et efficacement vos tests avec et ce, à moindre coût ? Par cette présentation, découvrez ou plutôt re-découvrez Selenium qui, avec toutes ses facettes, pourra vous amener beaucoup plus loin que vous ne le pensiez.
Authenticating, validating, caching, error handling, logging, documenting, testing and profiling are common features in web API, here are code samples to show how to implement them!
S'il est facile de comprendre l'intérêt d'un code bien testé, la mise en œuvre de tests se heurte souvent au problème des dépendances du code testé : comment s'abstraire de ces dépendances ?
A travers une présentation pratique, où Stéphane Malbéqui, Yannick Ameur et Anthony Dahanne rencontreront et résoudrons plusieurs obstacles à la mise en oeuvre de tests untiataires, vous découvrirez à travers un cas concret la mise en œuvre de TDD !
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
Outils et pratiques : tester une application web modernehalleck45
Introduction aux pratiques de testabilité logicielle : types de tests, outils. Présentation aux Rencontres Mondiales du Logiciel Libre 2014.
Vidéo : http://video.rmll.info/videos/tester-une-application-web-quels-outils-et-quelles-pratiques/
[Agile Testing Day] Techniques avancées de testsCellenza
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.
Au cours des derniers mois, j'ai rédigé plus de 600 tests unitaires (Peut-être plus, j'ai perdu le compte). Grâce à cette présentation, vous pourrez éviter de devenir aussi cinglé que moi en bénéficiant de mon expérience, alors que je vous expliquerais comment rédiger des tests avec les Fakes de Microsoft (autrefois appelés Moles), les obstacles à éviter, des trucs pour sauver du temps lors de la rédaction de tests, et à quelle déité païenne vous devez faire des sacrifices pour que tout fonctionne. À moins que je me sois trompé de livre...
Conférencier: Frédéric Simard
Il s'agit d'une initiation a l'utilisation des tests unitaires
La formation présentera les éléments suivants :
•Qu’est ce qu’un test ?
•Définition
•Quelques règles
•Avantage et intérêt
•Outil de test
•Cas à tester
•Les résultats
•Test Driven Development
•Mock
•Convention nommage
•Utilisation Junit
•Conclusion
Cette formation est proposée par ISEN Dev, un projet associatif étudiant de l'association Isen Engineering.
Elle est réalisé en 2013 par SAEZ Jonathan
Le Test Driven Infrastructure, c'est un peu le TDD pour les projets DevOps. Il va vous permettre de tester votre infrastructure unitairement, de bout en bout et à chaque changement.
Industrialiser le contrat dans un projet PHPhalleck45
La notion de contrat intervient à tous les étages en PHP : du code source au besoin fonctionnel, en passant par la nécessité de travailler en équipe ou de fournir un travail clair et compréhensible. Petit tour d'horizon des outils qui vous permettront de vous assurer automatiquement que ces contrats sont bien respectés.
Conférences lors du rendez-vous AFUP Nantes du 29 octobre 2012
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 ?
Le test, qu'il soit unitaire ou fonctionnel, est à la mode dans le monde du développement logiciel, suite entre autre à la mise en œuvre croissante des méthodes agiles et notamment de l'intégration continue ou des méthodes de développement telles que le TDD, le BDD ou la programmation par contrat. Récemment, ce phénomène a encore été amplifié au sein de la communauté PHP par l'apparition aux côtés de l'incontournable PHPUnit d'outils plus originaux tels que Behat, Praspel ou atoum qui permettent au développeur de rédiger des tests plus simplement. Pourtant, nous constatons tous les jours que le test conserve une grande part de mystère pour la plupart des développeurs, Bien souvent, ces derniers ne savent pas quoi tester, et encore moins comment écrire un test efficace ou mettre en place une politique de test pertinente. Certains s'interrogent par exemple sur la pertinence de leurs tests, se demandent s'il faut absolument tout tester, d'autres s'il est possible de tester la création d'un fichier, voir même s'il est intéressant de le faire, tandis que d'autres se demandent où se situe la frontière entre le test unitaire et le test fonctionnel ou s'il est nécessaire de tester toutes les méthodes d'une classe, alors que d'autres encore ne savent tout simplement pas par où commencer. Durant cette conférence, nous allons tenter, à l'aide de nos expériences respectives de créateur de framework de tests et de doctorat en informatique spécialisé dans le test, de répondre aux questions récurrentes que se pose une personne confrontée à la mise en place d'une politique de qualité logicielle en général et à l'écriture d'un test logiciel en particulier. À l'issue de cette foire aux questions didactique et interactive, vous devriez être capable d'aborder le test, indépendamment de sa nature, de manière plus sereine et efficace et produire ainsi un logiciel de la qualité que vous désirez.
Vous avez dit Selenium ? L'outil qui permet d'automatiser les tests fonctionnels ? Multi-langage ? Multi-plateforme ? Et vraiment intéressant pour garantir la qualité de votre projet tout au long de sa réalisation ?
Oui, il s'agit bien de l'outil multi-tâches que l'on gagne à connaître dans un monde Agile où la qualité de votre application ne peut pas être négligée.
Mais jusqu'à quel niveau avez-vous utilisé l'outil ? Avez-vous industrialisé durablement et efficacement vos tests avec et ce, à moindre coût ? Par cette présentation, découvrez ou plutôt re-découvrez Selenium qui, avec toutes ses facettes, pourra vous amener beaucoup plus loin que vous ne le pensiez.
Authenticating, validating, caching, error handling, logging, documenting, testing and profiling are common features in web API, here are code samples to show how to implement them!
S'il est facile de comprendre l'intérêt d'un code bien testé, la mise en œuvre de tests se heurte souvent au problème des dépendances du code testé : comment s'abstraire de ces dépendances ?
A travers une présentation pratique, où Stéphane Malbéqui, Yannick Ameur et Anthony Dahanne rencontreront et résoudrons plusieurs obstacles à la mise en oeuvre de tests untiataires, vous découvrirez à travers un cas concret la mise en œuvre de TDD !
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
Behaviour Driven Development with SpecFlowPascal Laurin
You may know TDD but do you know BDD? Just like its cousin Behaviour Driven Development is a technique focusing on development using automated tests but at the functional or behaviour level. Think automated acceptance testing using English sentences with a few extra keywords: Given, When and Then.
In this presentation I'll be using SpecFlow, a Visual Studio extension that help us write BDD style tests easily.
Pour vraiment profité des avantages du Cloud nous devons revoir comment concevoir nos applications. Heureusement il est possible d’obtenir une architecture efficace rapidement en suivant quelques bons conseils. Dans cette présentation je vais montrer quelques Design Patterns qui permettront à vos applications d’être plus performantes en général (et pas seulement sur le Cloud!).
Test and Behaviour Driven Development (TDD/BDD)Lars Thorup
In this introduction to Test Driven Development (TDD) or Behaviour Driven Development (BDD) we give a high level description of what it is and why it is useful for developers. Then we go into some details on stubs and mocks, test data, UI testing, SQL testing, JavaScript testing, web services testing and how to start doing TDD/BDD on an existing code base.
Ce cours présente la notion de qualité de code et comment il est possible de l'évaluer grâce à des métriques mesurables. Après avoir présenté plusieurs métriques standards, il se concentrer sur des aspects de qualité de code spécifique à l'orienté objet et présente les cinq concepts de l'orienté objet. La deuxième partie du cours présente plusieurs bonnes pratiques à avoir en programmation orientée objet, sur base d'exemples concrets.
(Slides de la présentation à la conférence Agile France 2010)
Vous avez lu la cheatsheet de JMock, la documentation d’EasyMock, la FAQ de Mockito et pourtant, la moitié de votre code n’est toujours pas couvert. Vous n’arrivez juste pas à poser de tests dessus.
Votre code est intestable.
L’objectif de la session est de montrer pourquoi certains codes ne peuvent pas être testés et ce qui peut être fait pour y remédier. Nous verrons ainsi pourquoi il vaut mieux respecter la loi de Demeter et faire de l’injection de dépendances. Nous aborderons également les problèmes des classes avec trop de responsabilités et des états globaux.
Rédigé en Mars 2013
Comment automatiser les tests ?
Les différents types de tests automatisés : TU, BDD/TDD, GUI, TDC, Test de vie …
Méthodes d’automatisation
Capture/replay
Projet de développement
Techniques d’automatisation
Data driven
Keyword driven
DSTL
Composants technique pour l’automatisation
Oracle
Bouchon
Techniques de comparaison
Reporting
Une base de données, pourquoi faire ? Le SQL, c’est quoi ce langage ? Un DBA, ça sert à quoi ? Cette session est là pour démystifier la base de données du point de vue des développeurs. Au programme : des bonnes pratiques, de la méthodologie, quelques tips techniques… De quoi rapprocher les développeurs et les DBA.
Tester unitairement une application javaAntoine Rey
Présente les différents types de tests automatisés, les objectifs des tests unitaires, les stratégies de mise en œuvre, les bonnes pratiques, les difficultés, ce qu'est un mock, différents outils (Unitils, Mockito, DbUnit, Spring Test) et des exemples de tests (DAO et contrôleurs Spring MVC), sans oublier le test de code legacy.
L’état de l’art des tests front-end
Maîtriser et fiabiliser son code sont aujourd’hui devenus incontournables pour tout développeur devant faire face à des architectures Web de plus en plus riches et complexes.
Il existe des outils pour réaliser des tests front-end d’applications Web et répondre aux besoins d’un développement de qualité.
Nous vous invitons ici à parcourir l’écosystème de ces tests front-end d’applications Web. Que vous soyez déjà convaincus par les tests ou tout simplement curieux, ce document vous guidera pour les mettre en place sur vos projets.
SQLSaturday Paris 2014 - Automatisez les tests de vos développements BI grâce...GUSS
Si vous voulez accélérer le testing de votre solution BI, sans devoir coder en .Net, la meilleure méthode est l’automatisation de tests via un framework dédié. Durant cette session, nous découvrirons la puissance du framework de tests, open-source, nommé NBi (nbi.codeplex.com) aussi bien sur les databases que sur les cubes ou les etls. Les démos nous permettrons de comprendre les meilleures techniques pour vérifier rapidement et sûrement la qualité de vos développements mais aussi comprendre comment minimiser le temps de développement et de maintenance de tels tests en utilisant les richesses de ce Framework. Session présentée lors du SQLSaturday Paris 2014
Automatiser les tests des développements BI grâce à NBiCédric Charlier
Pourquoi et comment automatiser les tests d'une solution BI? Ce slide deck met en avant les possibilités diverses et variées du framework NBi et explique comment réussir son automatisation des tests.
Paris Web 2015 - Atelier désendettement Javascript legacyFrançois Petitit
par Michael Akbaraly et François Petitit - OCTO Technology
Vous avez récupéré un projet JavaScript de plusieurs milliers de lignes, on vous demande des évolutions et des corrections de bugs, et rien ne va.
Code illisible, régressions en pagaille, structure des répertoires incompréhensibles : vous ne savez pas par où commencer !
Au long des 90 minutes de cet atelier, nous vous proposons de découvrir les techniques et les outils qui vont vous sauver la vie via des travaux pratiques de code JavaScript côté back-end avec NodeJS, et côté front-end avec AngularJS.
Débutants ou ayant déjà une connaissance de ces technologies sont les bienvenus. Les travaux pratiques seront disponibles si vous souhaitez coder vous-mêmes pendant l'atelier.
Similaire à L'amélioration des tests unitaires par le refactoring (20)
Paris Web 2015 - Atelier désendettement Javascript legacy
L'amélioration des tests unitaires par le refactoring
1. L'amélioration des tests
unitaires par le refactoring
Pascal Laurin
Mai 2015
@plaurin78
pascal.laurin@outlook.com
www.pascallaurin.com
Microsoft .NET MVP
Développeur & Architecte chez GSoft
2. Maintenance
Si on n’est pas capable de comprendre un test qui plante, il ne
sert pas à grand chose
Remplacer les tests inutiles
Apprendre refactoring
Moins risqué qu’avec du code de production
Portée plus réduite dans les tests
Un bon défi
On tombe parfois sur de bon challenges
On n’a pas toujours l’occasion de partir de zéro
Pourquoi refactorer les tests unitaires
3. Facile à comprendre
Facile à lire
On doit comprendre immédiatement ce qui se passe s’il échoue
Indépendant
Les tests doivent pouvoir s’exécuter dans n’importe quel ordre
Ne doit pas avoir de dépendances externes
Rapide
Exécution en moins de 0.01 secondes (ou 100 tests/seconde)
Doit tester une seule chose
Sinon il y a plusieurs raison d’échouer et le problème va être plus
difficile à diagnostiquer
3
Les bons tests unitaires
4. Nom de la méthode de test
Doit ce lire comme le résumé du test
Code du tests
Structurer par block Arrange, Act et Assert
Nom de variables significatives
Utilisation de méthodes utilitaires
Méthodes de création, arrange et assert pour faciliter la lecture
Utilisation de classes utilitaires et classes de base pour la réutilisation
des méthodes utilitaires
Cacher ce qui n'est pas pertinent aux tests
Setup répétitif, plomberie d'architecture, les mocks, les valeurs
littérales qui ne sont pas importantes, etc...
Éviter les valeurs hard-coder
Utilisation de valeurs aléatoire (avec AutoFixture)
4
Facile à comprendre
5. Pas basé sur l'état des tests précédents
Chaque test est responsable de l’état initial du système sous test
Éviter les bases de données et les web services externes
DDD, architecture hexagonale, mocker les dépendances
externes
Voir les prochaines slides
5
Indépendant
6. Le domaine d’affaire au centre
Les ports expose un API pour accéder au domaine
Les adaptateurs font le pont entre les ports et les
dépendances externes
6
Architecture Hexagonale (Ports & Adapters)
Domain
UI
API
Data Store
External
Services
Ports
Adapters
7. Séparer les différents sous-domaines
d’affaires dans leurs propres
« domaines / hexagones »
7
DDD et Bounded Contexts
8. On teste juste le domaine
Le test utilise les ports entrants dans le domaine
On mocks ou stubs la partie adaptateur
8
Tests Unitaires
Domain
Test
Unitaire
Mocks ou
Stubs
Ports
Adapters
9. On teste juste les adaptateurs
Le test utilise les ports sortants du domaine
Les adaptateurs appel les vrais dépendances externes
9
Tests d’Intégrations
Domain
Test
d’Intégration
Vrais
dépendances
externes
Ports
Adapters
10. Pas d'appel externe
Utilisation d’Interfaces pour fournir des « tests doubles » dans les
test unitaires
Utiliser le principe d’Inversion de Contrôle (IoC) et Injection de
Dépendances (DI)
Utiliser des Mocks (et mocking framework) pour se faciliter la vie
Séparer les tests d'intégrations/systèmes
Tests unitaires pour le domaine d’affaire
Tests d’intégration pour les adaptateurs vers les systèmes
externes
10
Rapide
11. Séparer les tests
Créer deux ou plusieurs tests à partir d’un test qui en fait trop
Extraire les tests d’intégrations
En cas d’échec le message doit être clair
Ajouter des traces au besoin
Toujours fournir une explication sur les Assert
Utiliser une libraires spécialiser (ie Fluent Assertions)
Arrange qui compare les objets attendus des objets
actuels
En implémentant ToString() (et/ou Equals() et GetHashCode())
Sérialisation Json pour comparer et afficher l’état des objets
11
Tester une seule chose
12. C'est difficile avant d'avoir l'architecture en place
Moins adapté pour la plomberie
Si on se trompe on doit changer beaucoup de tests
Tester au bon niveau pour ne pas avoir à modifier les
tests tout le temps
Éviter de tester les méthodes et classes privées
Focus sur les API publiques du domaine (les Ports)
Penser à extraire le code complexe dans son propre sous-
système au besoin
Commands and Queries
Facilite les tests car on ne teste pas les requêtes de la même
façon que les commandes (modifications au système)
12
Planifier le développement piloté par les tests
TDD
13. Références
SlideShare pour la présentation
• http://www.slideshare.net/PascalLaurin
BitBucket pour le code
• http://bit.ly/1ITLwca
DDD book by Eric Evans
• http://www.amazon.ca/dp/0321125215
DDD Quickly
• http://www.infoq.com/minibooks/domain-driven-design-quickly
FakeItEasy
• http://fakeiteasy.github.io/
AutoFixture
• https://github.com/AutoFixture/AutoFixture
Fasterflect
• https://fasterflect.codeplex.com/
Questions?
@plaurin78
pascal.laurin@outlook.com
www.pascallaurin.com