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

1 048 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
1 048
Sur SlideShare
0
Issues des intégrations
0
Intégrations
21
Actions
Partages
0
Téléchargements
26
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

    ×