La qualité au meilleur prixgrâce aux tests unitaires               PHP’tit Déj            «Software Quality»        26.10....
PrésentationGauthier Delamarre = Responsable des services @ VA Consulting = Architecte logiciel, formateur, coach = Expert...
La qualité logicielle ?
La qualité logicielle ? ≠ Non, les qualités logicielles
La qualité logicielle ? ≠ Non, les qualités logicielles     règles métier
La qualité logicielle ? ≠ Non, les qualités logicielles     règles métier     exigences fonctionnelles
La qualité logicielle ? ≠ Non, les qualités logicielles     règles métier     exigences fonctionnelles     normes et stand...
La qualité logicielle ? ≠ Non, les qualités logicielles         règles métier         exigences fonctionnelles         nor...
Règles métier
Règles métier= méthodes
Règles métier= méthodes   calculs
Règles métier= méthodes   calculs   traitements
Règles métier= méthodes   calculs   traitements   validation
Règles métier= méthodes       calculs       traitements       validation ...
Test manuel
Test manuel≠ prédictible
Test manuel≠ prédictible    dépend de l’opérateur
Test manuel≠ prédictible    dépend de l’opérateur≠ reproductible
Test manuel≠ prédictible    dépend de l’opérateur≠ reproductible    coûts prohibitifs
Test unitaire ?
Test unitaire ? ≠ tester une seule fois
Test unitaire ? ≠ tester une seule fois = test automatisé
Test automatisé ?
Test automatisé ?= prédictible
Test automatisé ?= prédictible    fiable
Test automatisé ?= prédictible    fiable= reproductible
Test automatisé ?= prédictible    fiable= reproductible    sans surcoût
Test Driven Development
Test Driven Development= guide la conception
Test Driven Development= guide la conception= assure la testabilité
Test Driven Development= guide la conception= assure la testabilité= overhead minime
Scénario d’exemple :                facturation
Définir une unité
Définir une unitéune classe
Définir une unitéune classe ≠ facture
Définir une unitéune classe ≠ facture    ligne de facture
Définir une unitéune classe ≠ facture    ligne de facture+ une méthode
Définir une unitéune classe ≠ facture    ligne de facture+ une méthode    total()
Définir une unitéune classe ≠ facture    ligne de facture+ une méthode    total()= unité
Premier Test Case
Premier Test Case quantité
Premier Test Case  quantité× prix unitaire
Premier Test Case  quantité× prix unitaire= prix total (de la ligne)
Créer le test
Créer le test public function testInvoiceLineTotal()
Créer le test public function testInvoiceLineTotal() {   $line = new InvoiceLine(2, 45);   $this->assertEquals(90, $line->...
Créer l’unité
Créer l’unité class InvoiceLine {    /* properties + constructor */    public function total()    {       return $this->_q...
Jouer le test # phpunit tests/models/InvoiceLineTest.php PHPUnit 3.7.8 by Sebastian Bergmann. . Time: 0 seconds, Memory: 2...
Prise en charge de la TVA
Prise en charge de la TVApublic function testInvoiceLineTotal(){  $line = new InvoiceLine(2, 45, 15);  $this->assertEquals...
Rejouer le test # phpunit tests/models/InvoiceLineTest.php PHPUnit 3.7.8 by Sebastian Bergmann. F Time: 0 seconds, Memory:...
Adapter l’unité
Adapter l’unité class InvoiceLine {    /* properties + constructor */    public function total()    {       $total = $this...
Rejouer le test # phpunit tests/models/InvoiceLineTest.php PHPUnit 3.7.8 by Sebastian Bergmann. . Time: 0 seconds, Memory:...
Résumé
Résumétester unitairement
Résumétester unitairement = gain de temps
Résumétester unitairement = gain de temps      au design de l’application
Résumétester unitairement = gain de temps      au design de l’application      à l’exécution des tests
Résumétester unitairement = gain de temps      au design de l’application      à l’exécution des tests = amélioration de l...
Résumétester unitairement = gain de temps      au design de l’application      à l’exécution des tests = amélioration de l...
Résumétester unitairement = gain de temps      au design de l’application      à l’exécution des tests = amélioration de l...
Résumétester unitairement = gain de temps      au design de l’application      à l’exécution des tests = amélioration de l...
Résumétester unitairement = gain de temps      au design de l’application      à l’exécution des tests = amélioration de l...
Résumétester unitairement = gain de temps      au design de l’application      à l’exécution des tests = amélioration de l...
Questions ?
Merci de votre attention ! Twitter           = @gdelamarre Mail           = gauthier.delamarre@           vaconsulting.lu
Prochain SlideShare
Chargement dans…5
×

La qualité au meilleur prix grâce aux tests unitaires

952 vues

Publié le

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.

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
952
Sur SlideShare
0
Issues des intégrations
0
Intégrations
16
Actions
Partages
0
Téléchargements
20
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • «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
  • La qualité au meilleur prix grâce aux tests unitaires

    1. 1. La qualité au meilleur prixgrâce aux tests unitaires PHP’tit Déj «Software Quality» 26.10.2012 - Luxembourg
    2. 2. PrésentationGauthier Delamarre = Responsable des services @ VA Consulting = Architecte logiciel, formateur, coach = Expert PHP depuis 1999
    3. 3. La qualité logicielle ?
    4. 4. La qualité logicielle ? ≠ Non, les qualités logicielles
    5. 5. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier
    6. 6. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier exigences fonctionnelles
    7. 7. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier exigences fonctionnelles normes et standards
    8. 8. La qualité logicielle ? ≠ Non, les qualités logicielles règles métier exigences fonctionnelles normes et standards ...
    9. 9. Règles métier
    10. 10. Règles métier= méthodes
    11. 11. Règles métier= méthodes calculs
    12. 12. Règles métier= méthodes calculs traitements
    13. 13. Règles métier= méthodes calculs traitements validation
    14. 14. Règles métier= méthodes calculs traitements validation ...
    15. 15. Test manuel
    16. 16. Test manuel≠ prédictible
    17. 17. Test manuel≠ prédictible dépend de l’opérateur
    18. 18. Test manuel≠ prédictible dépend de l’opérateur≠ reproductible
    19. 19. Test manuel≠ prédictible dépend de l’opérateur≠ reproductible coûts prohibitifs
    20. 20. Test unitaire ?
    21. 21. Test unitaire ? ≠ tester une seule fois
    22. 22. Test unitaire ? ≠ tester une seule fois = test automatisé
    23. 23. Test automatisé ?
    24. 24. Test automatisé ?= prédictible
    25. 25. Test automatisé ?= prédictible fiable
    26. 26. Test automatisé ?= prédictible fiable= reproductible
    27. 27. Test automatisé ?= prédictible fiable= reproductible sans surcoût
    28. 28. Test Driven Development
    29. 29. Test Driven Development= guide la conception
    30. 30. Test Driven Development= guide la conception= assure la testabilité
    31. 31. Test Driven Development= guide la conception= assure la testabilité= overhead minime
    32. 32. Scénario d’exemple : facturation
    33. 33. Définir une unité
    34. 34. Définir une unitéune classe
    35. 35. Définir une unitéune classe ≠ facture
    36. 36. Définir une unitéune classe ≠ facture ligne de facture
    37. 37. Définir une unitéune classe ≠ facture ligne de facture+ une méthode
    38. 38. Définir une unitéune classe ≠ facture ligne de facture+ une méthode total()
    39. 39. Définir une unitéune classe ≠ facture ligne de facture+ une méthode total()= unité
    40. 40. Premier Test Case
    41. 41. Premier Test Case quantité
    42. 42. Premier Test Case quantité× prix unitaire
    43. 43. Premier Test Case quantité× prix unitaire= prix total (de la ligne)
    44. 44. Créer le test
    45. 45. Créer le test public function testInvoiceLineTotal()
    46. 46. Créer le test public function testInvoiceLineTotal() { $line = new InvoiceLine(2, 45); $this->assertEquals(90, $line->total()); }
    47. 47. Créer l’unité
    48. 48. Créer l’unité class InvoiceLine { /* properties + constructor */ public function total() { return $this->_quantity * $this->_unitPrice; } }
    49. 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. 50. Prise en charge de la TVA
    51. 51. Prise en charge de la TVApublic function testInvoiceLineTotal(){ $line = new InvoiceLine(2, 45, 15); $this->assertEquals(103.5, $line->total());}
    52. 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. 53. Adapter l’unité
    54. 54. Adapter l’unité class InvoiceLine { /* properties + constructor */ public function total() { $total = $this->_quantity * $this->_unitPrice; return $total * (1 + ($this->_vat / 100)); } }
    55. 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. 56. Résumé
    57. 57. Résumétester unitairement
    58. 58. Résumétester unitairement = gain de temps
    59. 59. Résumétester unitairement = gain de temps au design de l’application
    60. 60. Résumétester unitairement = gain de temps au design de l’application à l’exécution des tests
    61. 61. Résumétester unitairement = gain de temps au design de l’application à l’exécution des tests = amélioration de la qualité
    62. 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. 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. 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. 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. 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. 67. Questions ?
    68. 68. Merci de votre attention ! Twitter = @gdelamarre Mail = gauthier.delamarre@ vaconsulting.lu

    ×