La qualité au meilleur prix grâce aux tests unitaires
•Als KEY, PDF herunterladen•
1 gefällt mir•1,083 views
Découvrez comment et pourquoi les tests unitaires sont le meilleur moyen d'assurer la qualité au coût le plus faible dans vos projets PHP.
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie La qualité au meilleur prix grâce aux tests unitaires
Ähnlich wie La qualité au meilleur prix grâce aux tests unitaires (20)
La qualité au meilleur prix grâce aux tests unitaires
- 1. La qualité au meilleur prix grâce aux tests unitaires PHP’tit Déj «Software Quality» 26.10.2012 - Luxembourg
- 2. Présentation Gauthier Delamarre = Responsable des services @ VA Consulting = Architecte logiciel, formateur, coach = Expert PHP depuis 1999
- 4. La qualité logicielle ? ≠ Non, les qualités logicielles
- 5. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier
- 6. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier exigences fonctionnelles
- 7. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier exigences fonctionnelles normes et standards
- 8. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier exigences fonctionnelles normes et standards ...
- 11. Règles métier = méthodes calculs
- 12. Règles métier = méthodes calculs traitements
- 13. Règles métier = méthodes calculs traitements validation
- 14. Règles métier = méthodes calculs traitements validation ...
- 15. Test manuel
- 17. Test manuel ≠ prédictible dépend de l’opérateur
- 18. Test manuel ≠ prédictible dépend de l’opérateur ≠ reproductible
- 19. Test manuel ≠ prédictible dépend de l’opérateur ≠ reproductible coûts prohibitifs
- 20. Test unitaire ?
- 21. Test unitaire ? ≠ tester une seule fois
- 22. Test unitaire ? ≠ tester une seule fois = test automatisé
- 24. Test automatisé ? = prédictible
- 25. Test automatisé ? = prédictible fiable
- 26. Test automatisé ? = prédictible fiable = reproductible
- 27. Test automatisé ? = prédictible fiable = reproductible sans surcoût
- 29. Test Driven Development = guide la conception
- 30. Test Driven Development = guide la conception = assure la testabilité
- 31. Test Driven Development = guide la conception = assure la testabilité = overhead minime
- 32. Scénario d’exemple : facturation
- 33. Définir une unité
- 34. Définir une unité une classe
- 35. Définir une unité une classe ≠ facture
- 36. Définir une unité une classe ≠ facture ligne de facture
- 37. Définir une unité une classe ≠ facture ligne de facture + une méthode
- 38. Définir une unité une classe ≠ facture ligne de facture + une méthode total()
- 39. Définir une unité une classe ≠ facture ligne de facture + une méthode total() = unité
- 41. Premier Test Case quantité
- 42. Premier Test Case quantité × prix unitaire
- 43. Premier Test Case quantité × prix unitaire = prix total (de la ligne)
- 44. Créer le test
- 45. Créer le test public function testInvoiceLineTotal()
- 46. Créer le test public function testInvoiceLineTotal() { $line = new InvoiceLine(2, 45); $this->assertEquals(90, $line->total()); }
- 47. Créer l’unité
- 48. Créer l’unité class InvoiceLine { /* properties + constructor */ public function total() { return $this->_quantity * $this->_unitPrice; } }
- 49. Jouer le test # phpunit tests/models/InvoiceLineTest.php PHPUnit 3.7.8 by Sebastian Bergmann. . Time: 0 seconds, Memory: 2.25Mb OK (1 test, 1 assertion)
- 50. Prise en charge de la TVA
- 51. Prise en charge de la TVA public function testInvoiceLineTotal() { $line = new InvoiceLine(2, 45, 15); $this->assertEquals(103.5, $line->total()); }
- 52. Rejouer le test # phpunit tests/models/InvoiceLineTest.php PHPUnit 3.7.8 by Sebastian Bergmann. F Time: 0 seconds, Memory: 2.50Mb There was 1 failure: 1) InvoiceLineTest::testInvoiceLineTotal Failed asserting that 90 matches expected 103.5. /Users/gauthier/projects/UnitTesting/tests/models/InvoiceLineTest.php:18 FAILURES! Tests: 1, Assertions: 1, Failures: 1.
- 53. Adapter l’unité
- 54. Adapter l’unité class InvoiceLine { /* properties + constructor */ public function total() { $total = $this->_quantity * $this->_unitPrice; return $total * (1 + ($this->_vat / 100)); } }
- 55. Rejouer le test # phpunit tests/models/InvoiceLineTest.php PHPUnit 3.7.8 by Sebastian Bergmann. . Time: 0 seconds, Memory: 2.25Mb OK (1 test, 1 assertion)
- 56. Résumé
- 58. Résumé tester unitairement = gain de temps
- 59. Résumé tester unitairement = gain de temps au design de l’application
- 60. Résumé tester unitairement = gain de temps au design de l’application à l’exécution des tests
- 61. Résumé tester unitairement = gain de temps au design de l’application à l’exécution des tests = amélioration de la qualité
- 62. Résumé tester unitairement = gain de temps au design de l’application à l’exécution des tests = amélioration de la qualité du code produit
- 63. Résumé tester unitairement = gain de temps au design de l’application à l’exécution des tests = amélioration de la qualité du code produit des fonctionnalités
- 64. Résumé tester unitairement = gain de temps au design de l’application à l’exécution des tests = amélioration de la qualité du code produit des fonctionnalités = industrialisation
- 65. Résumé tester unitairement = gain de temps au design de l’application à l’exécution des tests = amélioration de la qualité du code produit des fonctionnalités = industrialisation intégration continue
- 66. Résumé tester unitairement = gain de temps au design de l’application à l’exécution des tests = amélioration de la qualité du code produit des fonctionnalités = industrialisation intégration continue = gain de productivité
- 67. Questions ?
- 68. Merci de votre attention ! Twitter = @gdelamarre Mail = gauthier.delamarre@ vaconsulting.lu
Hinweis der Redaktion
- «A vaincre sans péril, on triomphe sans gloire»\n
- \n
- tests unitaires === tests techniques => tests d’implémentation des règles métiers\ntests unitaires == tests fonctionnels (dans une moindre mesure)\n
- tests unitaires === tests techniques => tests d’implémentation des règles métiers\ntests unitaires == tests fonctionnels (dans une moindre mesure)\n
- tests unitaires === tests techniques => tests d’implémentation des règles métiers\ntests unitaires == tests fonctionnels (dans une moindre mesure)\n
- tests unitaires === tests techniques => tests d’implémentation des règles métiers\ntests unitaires == tests fonctionnels (dans une moindre mesure)\n
- tests unitaires === tests techniques => tests d’implémentation des règles métiers\ntests unitaires == tests fonctionnels (dans une moindre mesure)\n
- - la plupart des méthodes métiers sont implémentées sous la forme de méthodes\n - ce sont elles qui représente l’essentiel de la valeur ajoutée d’une application\n - ces méthodes sont les unités auxquelles fait référence le terme «test unitaire»\n
- - la plupart des méthodes métiers sont implémentées sous la forme de méthodes\n - ce sont elles qui représente l’essentiel de la valeur ajoutée d’une application\n - ces méthodes sont les unités auxquelles fait référence le terme «test unitaire»\n
- - la plupart des méthodes métiers sont implémentées sous la forme de méthodes\n - ce sont elles qui représente l’essentiel de la valeur ajoutée d’une application\n - ces méthodes sont les unités auxquelles fait référence le terme «test unitaire»\n
- - la plupart des méthodes métiers sont implémentées sous la forme de méthodes\n - ce sont elles qui représente l’essentiel de la valeur ajoutée d’une application\n - ces méthodes sont les unités auxquelles fait référence le terme «test unitaire»\n
- - la plupart des méthodes métiers sont implémentées sous la forme de méthodes\n - ce sont elles qui représente l’essentiel de la valeur ajoutée d’une application\n - ces méthodes sont les unités auxquelles fait référence le terme «test unitaire»\n
- != prédictible => le résultat du test dépend de l’opérateur - de sa compréhension de la règle métier et de son interprétation du résultat\n!= coûts prohibitifs => chaque fois que le test est rejoué, il faut réinvestir le même temps - et ces temps d’exécution des tests croissent et se cumulent au long de la vie du projet\n
- != prédictible => le résultat du test dépend de l’opérateur - de sa compréhension de la règle métier et de son interprétation du résultat\n!= coûts prohibitifs => chaque fois que le test est rejoué, il faut réinvestir le même temps - et ces temps d’exécution des tests croissent et se cumulent au long de la vie du projet\n
- != prédictible => le résultat du test dépend de l’opérateur - de sa compréhension de la règle métier et de son interprétation du résultat\n!= coûts prohibitifs => chaque fois que le test est rejoué, il faut réinvestir le même temps - et ces temps d’exécution des tests croissent et se cumulent au long de la vie du projet\n
- != prédictible => le résultat du test dépend de l’opérateur - de sa compréhension de la règle métier et de son interprétation du résultat\n!= coûts prohibitifs => chaque fois que le test est rejoué, il faut réinvestir le même temps - et ces temps d’exécution des tests croissent et se cumulent au long de la vie du projet\n
- - test unitaire == test portant sur une unité\n - poser la question «qu’est-ce qu’un test unitaire ?» \n - indice : ce n’est pas un test effectué une seule fois - au contraire c’est un test automatisé\n
- - test unitaire == test portant sur une unité\n - poser la question «qu’est-ce qu’un test unitaire ?» \n - indice : ce n’est pas un test effectué une seule fois - au contraire c’est un test automatisé\n
- - impose la nécessité de tester des unités\n
- - impose la nécessité de tester des unités\n
- - impose la nécessité de tester des unités\n
- - impose la nécessité de tester des unités\n
- - permet de trouver plus vite la meilleure implémentation et facilite le refactoring\n - tester avant d’écrire le code garantit d’écrire du code testable\n - écrire les tests au fur et à mesure est plus fluide, et les gains immédiats équilibrent largement le temps investit dans l’écriture du test lui-même\n
- - permet de trouver plus vite la meilleure implémentation et facilite le refactoring\n - tester avant d’écrire le code garantit d’écrire du code testable\n - écrire les tests au fur et à mesure est plus fluide, et les gains immédiats équilibrent largement le temps investit dans l’écriture du test lui-même\n
- - permet de trouver plus vite la meilleure implémentation et facilite le refactoring\n - tester avant d’écrire le code garantit d’écrire du code testable\n - écrire les tests au fur et à mesure est plus fluide, et les gains immédiats équilibrent largement le temps investit dans l’écriture du test lui-même\n
- \n
- une unité = une classe + une méthode\n
- une unité = une classe + une méthode\n
- une unité = une classe + une méthode\n
- une unité = une classe + une méthode\n
- une unité = une classe + une méthode\n
- une unité = une classe + une méthode\n
- exemple volontairement trivial\n
- exemple volontairement trivial\n
- exemple volontairement trivial\n
- cette méthode est écrite dans une classe simple, héritant d’une classe du framework de test unitaire\nassertEquals = une assertion == un prédicat (les tests sont prédictibles...)\n
- cette méthode est écrite dans une classe simple, héritant d’une classe du framework de test unitaire\nassertEquals = une assertion == un prédicat (les tests sont prédictibles...)\n
- cette méthode est écrite dans une classe simple, héritant d’une classe du framework de test unitaire\nassertEquals = une assertion == un prédicat (les tests sont prédictibles...)\n
- cette méthode est écrite dans une classe simple, héritant d’une classe du framework de test unitaire\nassertEquals = une assertion == un prédicat (les tests sont prédictibles...)\n
- cette méthode est écrite dans une classe simple, héritant d’une classe du framework de test unitaire\nassertEquals = une assertion == un prédicat (les tests sont prédictibles...)\n
- \n
- \n
- \n
- on s’assure que les changements du test reflètent une véritable modification\n=> évite les assertions inutiles\n
- \n
- \n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- évidemment tout ceci demande un investissement initial (formation, pratique...)\n
- \n
- \n