Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

TDD où l’art de développer à l’endroit

239 vues

Publié le

Conférence de J. Fargeon lors de l'Agile Tour Aix-Marseille 2017

Publié dans : Logiciels
  • Soyez le premier à commenter

TDD où l’art de développer à l’endroit

  1. 1. 05/12/2017 #AgileTourSophia (par @AgileTourSophia) Agile Tour Sophia Antipolis 7ème édition – 5 décembre 2017 1 TDD où l’art de développer à l’endroit Julien FARGEON
  2. 2. 05/12/2017 #AgileTourSophia (par @AgileTourSophia) 2 Merci aux Sponsors !
  3. 3. 1.Agilité et Qualité 2.Les tests unitaires 3.TDD – Test Driven Development 4.Quelle approche choisir ? 5.Les styles de TDD © SOFTEAM Cadextan 2017
  4. 4. 1 QUALITÉ ET AGILITÉ © SOFTEAM Cadextan 2017 4
  5. 5. QUALITÉ ET AGILITÉ © SOFTEAM Cadextan 2017 5 Porter une attention continue à l’excellence technique 9ème principe du Manifeste Agile
  6. 6. QUALITÉ ET AGILITÉ – POURQUOI ? © SOFTEAM Cadextan 2017 6 Favoriser l’adaptation au changement plus que le suivi d’un plan 4ème valeur du Manifeste Agile
  7. 7. QUALITÉ ET AGILITÉ © SOFTEAM Cadextan 2017 7
  8. 8. QUALITÉ ET AGILITÉ · Vu sur le Web… │ Any fool can write code that a computer can understand. Good programmers write code that Humans can understand.
 Martin Fowler │ My project is 90 % done. I hope the second half goes as well.
 Scott W. Ambler │ Codez toujours en pensant que celui maintiendra votre code est un psychopathe qui connait votre adresse.
 Martin Golding © SOFTEAM Cadextan 2017 8
  9. 9. QUALITÉ ET AGILITÉ © SOFTEAM Cadextan 2017 9 Une application informatique est de qualité lorsque
 le coût d’ajout d’une fonctionnalité reste stable
  10. 10. STRATÉGIE DE TESTS HABITUELLE © SOFTEAM Cadextan 2017 10 Spécification Réalisation Tests
  11. 11. QUALITÉ ET AGILITÉ · Les problèmes qui surviennent: │ « La spécification est mal comprise par les développeurs » │ « La spécification a été interprétée » │ « Vous n’avez pas compris ce qu’on voulait! » │ « Ce n’est pas ce que dit la spécification! » │ « Aurais-tu un exemple à me donner pour que je comprenne un peu mieux ? » │ « Les développeurs ne comprennent rien à notre métier » │ « Le client ne connaît pas l’informatique! » © SOFTEAM Cadextan 2017 11
  12. 12. QUALITÉ ET AGILITÉ · Travailler en collaboration : │ Des spécifications sont basées sur des exemples: • Rassurent l’équipe quant à la conformité au besoin • Réduisent les possibles mauvaises interprétations • Cassent la barrière d’un langage métier parfois complexe © SOFTEAM Cadextan 2017 12
  13. 13. QUALITÉ ET AGILITÉ · Exemples de spécifications par l’exemple: │ Calculatrice • Lorsque je saisis 30, j’appuie sur le bouton ‘+’, je saisis 45, j’appuie sur le bouton égal, alors j’obtiens 75 │ Orthodromie • La distance orthodromique entre Paris (48°51’N – 2°21’E) et Montpellier (43°36’N – 3°53’E) et de 595 Kms │ Calcul d’agios • Sur le 4ème trimestre 2012, un compte est débiteur de 451€ du 13/11 au 28/11 et de 342€ du 08/12 au 27/12, avec un taux d’intérêt de 20% annuel. Les intérêts sur la période sont de 7,27€ © SOFTEAM Cadextan 2017 13
  14. 14. QUALITÉ ET AGILITÉ · Ce qui est essentiel : · © SOFTEAM Cadextan 2017 14
  15. 15. PILOTAGE PAR LES TESTS · Principe : · Ces tests vont guider le développement et la conception © SOFTEAM Cadextan 2017 15
  16. 16. APPROCHE AGILE · Vision de l’avancement dans un projet traditionnel : © SOFTEAM Cadextan 2017 16 Analyse Design Dev Test Avancement
  17. 17. APPROCHE AGILE · Vision de l’avancement dans un projet Agile : © SOFTEAM Cadextan 2017 17 Avancement Analyse Design Dev Test Fct 1 Fct N …
  18. 18. QUADRANT DE TEST AGILE © SOFTEAM Cadextan 2017 18 Fonctionnels Exemples Démos Acceptation Prototype Exploratoires Utilisateur Ergonomiques Alpha/beta Unitaires Intégration Composant Performance Sécurité Rupture Aideaudéveloppement Métier Technique Aideàlavalidation
  19. 19. QUE FAUT-IL TESTER? · Pyramide des tests de Mike Cohn © SOFTEAM Cadextan 2017 19 UI Intégration Unitaires
  20. 20. AUTOMATISATION · Pourquoi automatiser les tests ? © SOFTEAM Cadextan 2017 20 Feedback
 Permanent
  21. 21. EXTREME PROGRAMMING © SOFTEAM Cadextan 2017 21 http://www.extremeprogramming.org/map/images/loop.gif
  22. 22. POURQUOI AUTOMATISER LES TESTS? · Economiquement pertinent │ Dans la majorité des cas │ Dépend notamment de la durée de vie de l’application et
 du coût du bug en production · Plus fiable qu’un test manuel de l’ensemble du système · Pour réaliser des opérations complexes exécutables par une machine · Garantir le Feedback du bon fonctionnement de tout ce qui a été développé · Radiateur d’information : Améliore l’ambiance et le moral de l’équipe par rapport à ce qui a été accomplis © SOFTEAM Cadextan 2017 22
  23. 23. 2 LES TESTS UNITAIRES © SOFTEAM Cadextan 2017 23
  24. 24. DÉFINITIONS · Un test unitaire est un test… │Portant sur une ou partie de l’application testable et la plus petite possible, isolée du reste de l’application │Qui détermine si cette partie s’exécute correctement vis-à-vis d’un comportement attendu · Partie de code testée = SUT │SUT : System Under Test │Peut être une classe ou un petit ensemble de classe (namespace/ package) · Un test est avant tout un exemple ! │Exprimé avec des données significatives © SOFTEAM Cadextan 2017 24
  25. 25. EXEMPLE DE TEST UNITAIRE © SOFTEAM Cadextan 2017 25 [TestClass] class CalculatorTests { [TestMethod] public void shouldAddTwoNumbers() { Calculator calculator = new Calculator(); int result = calculator.Add(1,2); Assert.AreEqual(3, result); } }
  26. 26. STRUCTURE D’UN TEST UNITAIRE · Structure de base : 3 A │Arrange │Act │Assert © SOFTEAM Cadextan 2017 26 [TestClass] class CalculatorTests { [TestMethod] public void shouldAddTwoNumbers() { // Arrange Calculator calculator = new Calculator(); // Act int result = calculator.Add(1,2); // Assert Assert.AreEqual(3, result); } }
  27. 27. STRUCTURE D’UN TEST UNITAIRE · Structure issue du BDD │Given │When │Then © SOFTEAM Cadextan 2017 27 [TestClass] class CalculatorTests { [TestMethod] public void shouldAddTwoNumbers() { // Given Calculator calculator = new Calculator(); // When int result = calculator.Add(1,2); // Then Assert.AreEqual(3, result); } }
  28. 28. ORGANISATION D’UN TEST UNITAIRE · 1 méthode par test · 1 concept testé par test │= 1 assertion ? │Ex : Calculator • 1 test pour la division • 1 test pour la division par zéro · 1 classe de test par SUT (System Under Test) │« Single Responsibility Principle » (S.O.L.I.D) © SOFTEAM Cadextan 2017 28
  29. 29. LIBRAIRIES DE TESTS UNITAIRES · Plusieurs librairies en fonction des langages │ xUnit • La plus populaire • Junit, Nunit, CppUnit, etc. │ Jmockit, Mockito │ PITest │ Etc. · Déclaration, préparation et nettoyage
 des tests par annotations (ex: Java) · Utilisation d’assertions │ Rendent le test auto-validant │ Disponibles sous forme de classes et méthodes fournies
 par les frameworks • assertEquals, assertNull • assertFalse, assertTrue, fail • Etc. © SOFTEAM Cadextan 2017 29 @Test public void test_method_1() { System.out.println("@Test - test_method_1"); } // Run once, e.g. Database connection, connection pool @BeforeClass public static void runOnceBeforeClass() { System.out.println("@BeforeClass - runOnceBeforeClass"); } // Run once, e.g close connection, cleanup @AfterClass public static void runOnceAfterClass() { System.out.println("@AfterClass - runOnceAfterClass"); } // Should rename to @BeforeTestMethod // e.g. Creating an similar object and share for all @Test @Before public void runBeforeTestMethod() { System.out.println("@Before - runBeforeTestMethod"); } // Should rename to @AfterTestMethod @After public void runAfterTestMethod() { System.out.println("@After - runAfterTestMethod"); }
  30. 30. MNÉMOTECHNIQUE · F.I.R.S.T. │Fast │Independant │Repeatable │Self-Validating │Timely © SOFTEAM Cadextan 2017 30
  31. 31. 3 TDD – TEST DRIVEN DEVELOPMENT © SOFTEAM Cadextan 2017 31
  32. 32. DÉFINITION TDD Test · Driven · Development © SOFTEAM Cadextan 2017 32 Discipline de conception Conception émergente Centré sur le besoin Refactoring intensif
  33. 33. DÉFINITION TDD · Test Driven Development │La rédaction des tests est la première étape de la formalisation du codage │Chaque élément de code n’est écrit QUE pour permettre de passer le test │À chaque modification du code : • on lance tous les tests écrits par tous les développeurs • On sait immédiatement si quelque chose ne fonctionne plus │Les tests sont conservés et maintenus jusqu’à la fin du projet │Le code est remanié · Avantages : │Interaction entre les cas de tests et la compréhension fine des besoins fonctionnels │Adhérence du code aux tests • Intégration forte de la qualité logicielle │Le code écrit en TDD est plus maintenable, mieux découpé │Sécurise le développement © SOFTEAM Cadextan 2017 33 Communication !
  34. 34. LE CYCLE TDD 1. Étapes : 1. RED 2. GREEN 3. REFACTOR © SOFTEAM Cadextan 2017 34 http://dbottiau.azurewebsites.net/unit-testing/
  35. 35. PROCESSUS TRADITIONNEL © SOFTEAM Cadextan 2017 35 Spécification Développement Tests Design Non testable Bugs
  36. 36. TDD © SOFTEAM Cadextan 2017 36 Spécification Développement Tests Design Cycles très courts FAIL FAST, FAIL SAFE
  37. 37. EN RÉSUMÉ · TDD : │1 discipline de conception de code │1 cycle : RED – GREEN – REFACTOR • Approche test F.I.R.S.T. · Intérêt du test First : │Le test est écrit │Le code testé est testable par nature • Donc le design est meilleur │Les assertions sont validées • Par l’étape RED │Nécessite de se focaliser sur ce qui est nécessaire • Evite d’écrire du code inutile │Chaque test est un pas en avant │Le debugger est beaucoup moins nécessaire © SOFTEAM Cadextan 2017 37
  38. 38. DESIGN EMERGEANT · « First make it work, then make it right » │Le code fonctionne │Le code est ensuite refactoré · Refactoring │Elimination de la duplication │Couplage lâche · Les classes et méthodes créées le sont par nécessité · Le refactoring est réalisé en permanence │Chaque opportunité d’améliorer le code est saisie (Scout toujours !) │Les tests sont là en protection, à tout moment © SOFTEAM Cadextan 2017 38
  39. 39. MNÉMOTECHNIQUE - SIMPLICITÉ · Y.A.G.N.I. │ « You aren’t Gonna Need It ! » │ Tout ce qui n’est pas absolument utile à un moment donnée n’est pas implémenté │ Pas d’optimisation prématurée · Les décisions sont retardées │ Eviter de payer le coût de décision prises trop tôt · Faire appel aux patterns quand il le faut │ Inutile d’appliquer des patterns si le besoin n’est pas réel · Faire simple ≠ Facile │ Il est difficile de faire simple © SOFTEAM Cadextan 2017 39
  40. 40. 4 QUELLE APPROCHE CHOISIR? © SOFTEAM Cadextan 2017 40
  41. 41. 2 APPROCHES TDD · Approche Middle-out │Avantages : • Permet de se concentrer d’abord sur le domaine • Séparation des préoccupations plus simples │Inconvénients : • Peut conduire à en faire « trop », 
 au-delà de ce qui est nécessaire © SOFTEAM Cadextan 2017 41 UI Services Data Access Domain
  42. 42. 2 APPROCHES TDD · Approche Outside-In │Avantages : • Tout est guidé par le besoin primaire │Inconvénients : • Peut conduire à donner trop de responsabilités
 aux préoccupations de haut niveau © SOFTEAM Cadextan 2017 42 UI Services Data Access Domain
  43. 43. 5 LE TDD C’EST STYLÉ © SOFTEAM Cadextan 2017 43
  44. 44. LES DOUBLURES Tester une classe qui n’a aucune dépendance est généralement assez simple. La difficulté va commencer à se faire sentir (et cela devrait arriver presque tout le temps) lorsque les classes vont utiliser des dépendances. Nous avons deux solutions pour tester une classe : 1.Tester la classe avec toutes ses dépendances, et si vous comptez faire ça, alors il serait bien que vous sortiez (Nan mais restez car le plus important c’est de tester le comportement de la classe). 2.Ou bien, nous pouvons essayer d’isoler notre classe de ses dépendances : C’est là où interviennent les tests doubles. © SOFTEAM Cadextan 2017 44
  45. 45. LES DOUBLURES · Doublures │Terme générique qui identifie les objets utilisés en remplacement d’autres objets à des fins de test │Duplications de classes qui sont plus coopérative que les vrais !! · Permettent d’isoler le SUT du reste de système │Et donc d’écrire de vrais tests unitaires · Simplifient l’exécution du test │Pas besoin d’un environnement spécifique · Rendent l’exécution du test plus rapide © SOFTEAM Cadextan 2017 45
  46. 46. LES DUMMIES · Inoffensifs · Servent de paramètres à une méthode ou à un constructeur · Permettent simplement d’appeler correctement la méthode ou le constructeur · N’ont pas d’influence sur le code testé │ Sinon c’est un fake ou un mock © SOFTEAM Cadextan 2017 46 DUMMY N’EST RIEN D’AUTRE QU’UNE CLASSE DONT ON SE FICHE DE COMMENT ELLE EST UTILISÉE.
  47. 47. LES DUMMIES © SOFTEAM Cadextan 2017 47 interface UserInterface { public function getPassword(); public function getUsername(); } class DummyUser implements UserInterface { public function getPassword() { return null; } public function getUsername() { return null; } }
  48. 48. LES STUBS · Paramétrés pour se comporter d’une certaine façon et retourner certaines valeurs… © SOFTEAM Cadextan 2017 48 http://xunitpatterns.com
  49. 49. LES STUBS © SOFTEAM Cadextan 2017 49 http://xunitpatterns.com UN STUB EST UNE CLASSE QUI VA RÉPONDRE EXACTEMENT CE QUE J’ATTENDS class StubUser implements UserInterface { public function getPassword() { return 'foo'; } public function getUsername() { return 'Marvin'; } } class SendEmail { private $user; public function __construct(UserInterface $user) { $this->user = $user; } public function forgotPassword() { return sprintf( 'Hi %s, your password is %s', $this->user->getUsername(), $this->user->getPassword() ); } }
  50. 50. LES FAKES · Remplace une implémentation existante en rendant son utilisation plus appropriée pour les tests │ Exemple : base de données © SOFTEAM Cadextan 2017 50 http://xunitpatterns.com UN FAKE EST UN PEU COMME UN STUB, MAIS AVEC UN PEU DE LOGIQUE, UNE SORTE DE MINI-IMPLÉMENTATION DE LA VRAIE CLASSE
  51. 51. LES SPIES · Un stub qui enregistre des informations lorsqu’il est appelée, ces informations servant lors des assertions │ Exemple : Serveur de mails © SOFTEAM Cadextan 2017 51 UN SPY VA AVOIR LE MÊME COMPORTEMENT QU’UN STUB, MAIS IL VA NOUS PERMETTRE D’OBTENIR DES INFORMATIONS SUPPLÉMENTAIRES, UNE FOIS LE TEST EFFECTUÉ.
  52. 52. LES MOCKS · Stubs dont on vérifie s’ils se sont comportés comme prévu © SOFTEAM Cadextan 2017 52 IL S’AGIT SIMPLEMENT D’UN OBJET QUI EST UNE SUBSTITUTION COMPLÈTE DE L’IMPLÉMENTATION ORIGINALE D’UNE CLASSE CONCRÈTE
  53. 53. LES MOCKS © SOFTEAM Cadextan 2017 53 class MockUser implements UserInterface { private $numberCalled = 0; private $numberShouldBeCalled = 0; public function getPassword() { return 'foo'; } public function getUserName() { $this->numberCalled++; return 'Marvin'; } public function setExpectedNumberCalls($number) { $this->numberShouldBeCalled = $number; } public function verify() { if ($this->numberShouldBeCalled != $this->numberCalled) { throw new Exception(sprintf( 'Actual number of calls %d - expected %d.', $this->numberCalled, $this->numberShouldBeCalled )); } return true; } } L’UTILITÉ D’UN MOCK : UNE VÉRIFICATION COMPORTEMENTALE
  54. 54. DES QUESTIONS? © SOFTEAM Cadextan 2017 54
  55. 55. DES QUESTIONS? © SOFTEAM Cadextan 2017 55
  56. 56. DES QUESTIONS? © SOFTEAM Cadextan 2017 56
  57. 57. 05/12/2017 #AgileTourSophia (par @AgileTourSophia) 57 Merci aux Sponsors ! Julien FARGEON

×