The document discusses unit testing and the PHPUnit testing framework. It provides an overview of what unit testing is, why it is useful, and how to get started with PHPUnit. Key points include that unit testing finds bugs early, encourages good coding practices, and makes codebases easier to change and deploy. PHPUnit is introduced as the most popular PHP testing framework. Instructions are given for installing PHPUnit via PEAR and writing basic tests, including test fixtures, assertions, and annotations. More advanced topics like mock objects, data providers, and exception testing are also covered.
This document provides an overview of test driven development with PHPUnit. It discusses what unit testing is, the benefits of testing, and how to get started with PHPUnit. Key topics covered include writing tests, assertions, dependencies, data providers, testing errors and exceptions, fixtures, and database testing. The document also mentions test output, incomplete/skipped tests, test doubles, code coverage analysis, and the skeleton generator.
Les bonnes pratiques qui permettent d'encadrer une équipe de développement sont nombreuses.
Nous proposons ici une chronologie pour les mettre en place dans un ordre cohérent, qui permettra d'en faciliter l'acceptation et d'en maximiser les bénéfices.
Le tout dans le contexte d'une équipe professionnelle qui ne perd pas de vue que sa mission est de satisfaire les besoins de son client !
Ces slides sont une version adaptée à la consultation en ligne d'une conférence présentée les 29 et 30 Novembre dans le cadre du PHP Tour 2012 à Nantes.
Unit testing, everyone talks about it and wants to do it but never gets around to actually start testing. Complex spaghetti code and time / budget pressures are often the reasons why nobody dives in and gets started with testing. But when the application breaks, and people loose money or worse it's often too late.
In this talk I will take you on a journey with real examples that will show you how you can set up your tests, how to test complex situations with legacy spaghetti code, test web services, database interactions and how to gradually build a solid foundation to safeguard the core code base and everything around it.
Don't you want to be confident when you walk out the office?
This document introduces unit testing with PHPUnit. It discusses what unit testing is, why it's important, and tools like SimpleTest and PHPUnit. It provides examples of basic unit tests for a HelloWorld class using PHPUnit. It also covers more advanced testing techniques like data providers, expected exceptions, fixtures, doubles, mocks, stubs, and database testing using examples like testing a BankAccount class. The document provides hints and tips for unit testing MVC frameworks like Zend Framework.
The document discusses unit testing and the PHPUnit testing framework. It provides an overview of what unit testing is, why it is useful, and how to get started with PHPUnit. Key points include that unit testing finds bugs early, encourages good coding practices, and makes codebases easier to change and deploy. PHPUnit is introduced as the most popular PHP testing framework. Instructions are given for installing PHPUnit via PEAR and writing basic tests, including test fixtures, assertions, and annotations. More advanced topics like mock objects, data providers, and exception testing are also covered.
This document provides an overview of test driven development with PHPUnit. It discusses what unit testing is, the benefits of testing, and how to get started with PHPUnit. Key topics covered include writing tests, assertions, dependencies, data providers, testing errors and exceptions, fixtures, and database testing. The document also mentions test output, incomplete/skipped tests, test doubles, code coverage analysis, and the skeleton generator.
Les bonnes pratiques qui permettent d'encadrer une équipe de développement sont nombreuses.
Nous proposons ici une chronologie pour les mettre en place dans un ordre cohérent, qui permettra d'en faciliter l'acceptation et d'en maximiser les bénéfices.
Le tout dans le contexte d'une équipe professionnelle qui ne perd pas de vue que sa mission est de satisfaire les besoins de son client !
Ces slides sont une version adaptée à la consultation en ligne d'une conférence présentée les 29 et 30 Novembre dans le cadre du PHP Tour 2012 à Nantes.
Unit testing, everyone talks about it and wants to do it but never gets around to actually start testing. Complex spaghetti code and time / budget pressures are often the reasons why nobody dives in and gets started with testing. But when the application breaks, and people loose money or worse it's often too late.
In this talk I will take you on a journey with real examples that will show you how you can set up your tests, how to test complex situations with legacy spaghetti code, test web services, database interactions and how to gradually build a solid foundation to safeguard the core code base and everything around it.
Don't you want to be confident when you walk out the office?
This document introduces unit testing with PHPUnit. It discusses what unit testing is, why it's important, and tools like SimpleTest and PHPUnit. It provides examples of basic unit tests for a HelloWorld class using PHPUnit. It also covers more advanced testing techniques like data providers, expected exceptions, fixtures, doubles, mocks, stubs, and database testing using examples like testing a BankAccount class. The document provides hints and tips for unit testing MVC frameworks like Zend Framework.
Bonnes pratiques de developpement en PHPPascal MARTIN
Du haut de ses 14 ans, PHP est devenu une technologie utilisée pour de gros projets ; ce qui signifie besoins importants en termes de qualité, de robustesse, et d'outils de développement fiables.
Contrôle de sources, normes de codage, utilisation de Frameworks, documentation, tests unitaires / fonctionnels automatisés, intégration continue, déploiement, ...
Cette présentation a pour but d'introduire quelques bonnes pratiques de développement, ainsi que des outils permettant de les mettre en place sur des projets PHP.
PHPUnit is an automated unit testing framework for PHP. It allows developers to write tests for their code in PHP and run those tests to determine if the code is working as expected. Some key aspects of PHPUnit include writing tests in classes that extend the PHPUnit test case class, using assertions to validate expected outcomes, and the ability to test databases and output using PHPUnit extensions. PHPUnit is widely used for test-driven development in PHP projects.
Quel est ce nouveau langage? Description des termes du Web, du Cloud, des réseaux sociaux, et plus!
Conférence de Marc-André Léger (Université de Sherbrooke) dans le cadre du Rendez-vous des TIC 2012 sous le thème «Le Web pour les nuls et pour les pros», le 25 octobre 2012 à Sherbrooke.
» Visionnez la conférence captée en direct :
http://youtu.be/hfT7uYb7gGE
» Voyez les photos de l'évènement :
http://www.flickr.com/photos/sherbrooke-innopole/sets/72157631902409437/
» Accédez aux résumés des conférences :
#1 Résumé de la journée :
http://www.sherbrooke-innopole.org/technologies-information-communication/2012/11/14/1-le-rendez-vous-des-tic-2012-une-journee-branchee-reussie/
#2 Pour les NULS :
http://www.sherbrooke-innopole.org/technologies-information-communication/2012/11/14/2-rendez-vous-des-tic-2012-le-web-pour-les-nuls/
#3 Pour les PROS :
http://www.sherbrooke-innopole.org/technologies-information-communication/2012/11/14/3-rendez-vous-des-tic-2012-des-astuces-de-pros/
» Écoutez les entrevues du journaliste Rémy Perras d'Au Microphone :
http://www.aumicrophone.com/?s=rendez-vous+des+tic
El documento describe las acciones tomadas por el gobierno de Misiones, Argentina para implementar un programa de educación intercultural bilingüe para niños y jóvenes de la etnia Mbya entre 2004 y 2007. Estas acciones incluyen consultas con la comunidad Mbya, capacitación para docentes, desarrollo de materiales educativos en la lengua Mbya y la designación de auxiliares docentes indígenas.
Intervention de B. Le Lan lors de la journée technique organisée par la FROTSI Centre - Val de Loire le 29 novembre 2013, à Nouan-Le-Fuzellier. Présentation de l'évolution de la gouvernance sur le territoire de Morlaix Communauté entre 2007 et 2013. Il s'agit d'une réactualisation de la présentation faite au congrès des directeurs de 2012 à Mulhouse.
Présentation de la stratégie de la Maison du tourisme "Baie de Morlaix - Monts d'Armée" sur la double problématique de la gouvernance touristique et du etourisme, le 29 janvier 2013, devant une délégation du Pays de Coutances.
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire
ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la
conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.
Strategie de test à agile tour bordeauxNicolas Fédou
Une stratégie de tests, on sait tous que c’est nécessaire, mais sans forcément savoir à quoi ça ressemble.
Une stratégie de tests est la façon de s’organiser pour montrer qu’une application est de qualité suffisante pour aller en production. Il ne s’agit donc pas d’un inventaire de tests manuels ou automatisés, mais d’un raisonnement avec des choix et des renoncements.
Dans cette présentation nous verrons comment une stratégie de tests vise à optimiser la confiance et les preuves de qualité dans le cadre du développement d’un produit agile.
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
Formation Extreme Programming, Tests unitaires, travail collaboratifkemenaran
Cette formation développe les méthodes de l'Extreme Programming, introduit les tests unitaires et le Test Driven Developpement sous différents frameworks (dont CakePHP), et présente différents outils de travail collaboratif : SVN, Make, Trac, etc.
Rédigé en Mars 2013
Introduction : ce que l’on va couvrir (et ne pas couvrir)
Définition : Qu’est-ce que l’automatisation des tests ?
Objectifs : Pourquoi automatiser ?
Couverture :
Qu’est-ce qu’on automatise ?
Pre et Post Process
Comment déterminer ce qu’on automatise ?
Responsabilité : Qui fait quoi?
ROI : Combien ça coute ?
Infrastructure de test
Processus d’automatisation
Conclusion
Bonnes pratiques de developpement en PHPPascal MARTIN
Du haut de ses 14 ans, PHP est devenu une technologie utilisée pour de gros projets ; ce qui signifie besoins importants en termes de qualité, de robustesse, et d'outils de développement fiables.
Contrôle de sources, normes de codage, utilisation de Frameworks, documentation, tests unitaires / fonctionnels automatisés, intégration continue, déploiement, ...
Cette présentation a pour but d'introduire quelques bonnes pratiques de développement, ainsi que des outils permettant de les mettre en place sur des projets PHP.
PHPUnit is an automated unit testing framework for PHP. It allows developers to write tests for their code in PHP and run those tests to determine if the code is working as expected. Some key aspects of PHPUnit include writing tests in classes that extend the PHPUnit test case class, using assertions to validate expected outcomes, and the ability to test databases and output using PHPUnit extensions. PHPUnit is widely used for test-driven development in PHP projects.
Quel est ce nouveau langage? Description des termes du Web, du Cloud, des réseaux sociaux, et plus!
Conférence de Marc-André Léger (Université de Sherbrooke) dans le cadre du Rendez-vous des TIC 2012 sous le thème «Le Web pour les nuls et pour les pros», le 25 octobre 2012 à Sherbrooke.
» Visionnez la conférence captée en direct :
http://youtu.be/hfT7uYb7gGE
» Voyez les photos de l'évènement :
http://www.flickr.com/photos/sherbrooke-innopole/sets/72157631902409437/
» Accédez aux résumés des conférences :
#1 Résumé de la journée :
http://www.sherbrooke-innopole.org/technologies-information-communication/2012/11/14/1-le-rendez-vous-des-tic-2012-une-journee-branchee-reussie/
#2 Pour les NULS :
http://www.sherbrooke-innopole.org/technologies-information-communication/2012/11/14/2-rendez-vous-des-tic-2012-le-web-pour-les-nuls/
#3 Pour les PROS :
http://www.sherbrooke-innopole.org/technologies-information-communication/2012/11/14/3-rendez-vous-des-tic-2012-des-astuces-de-pros/
» Écoutez les entrevues du journaliste Rémy Perras d'Au Microphone :
http://www.aumicrophone.com/?s=rendez-vous+des+tic
El documento describe las acciones tomadas por el gobierno de Misiones, Argentina para implementar un programa de educación intercultural bilingüe para niños y jóvenes de la etnia Mbya entre 2004 y 2007. Estas acciones incluyen consultas con la comunidad Mbya, capacitación para docentes, desarrollo de materiales educativos en la lengua Mbya y la designación de auxiliares docentes indígenas.
Intervention de B. Le Lan lors de la journée technique organisée par la FROTSI Centre - Val de Loire le 29 novembre 2013, à Nouan-Le-Fuzellier. Présentation de l'évolution de la gouvernance sur le territoire de Morlaix Communauté entre 2007 et 2013. Il s'agit d'une réactualisation de la présentation faite au congrès des directeurs de 2012 à Mulhouse.
Présentation de la stratégie de la Maison du tourisme "Baie de Morlaix - Monts d'Armée" sur la double problématique de la gouvernance touristique et du etourisme, le 29 janvier 2013, devant une délégation du Pays de Coutances.
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire
ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la
conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.
Strategie de test à agile tour bordeauxNicolas Fédou
Une stratégie de tests, on sait tous que c’est nécessaire, mais sans forcément savoir à quoi ça ressemble.
Une stratégie de tests est la façon de s’organiser pour montrer qu’une application est de qualité suffisante pour aller en production. Il ne s’agit donc pas d’un inventaire de tests manuels ou automatisés, mais d’un raisonnement avec des choix et des renoncements.
Dans cette présentation nous verrons comment une stratégie de tests vise à optimiser la confiance et les preuves de qualité dans le cadre du développement d’un produit agile.
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
Formation Extreme Programming, Tests unitaires, travail collaboratifkemenaran
Cette formation développe les méthodes de l'Extreme Programming, introduit les tests unitaires et le Test Driven Developpement sous différents frameworks (dont CakePHP), et présente différents outils de travail collaboratif : SVN, Make, Trac, etc.
Rédigé en Mars 2013
Introduction : ce que l’on va couvrir (et ne pas couvrir)
Définition : Qu’est-ce que l’automatisation des tests ?
Objectifs : Pourquoi automatiser ?
Couverture :
Qu’est-ce qu’on automatise ?
Pre et Post Process
Comment déterminer ce qu’on automatise ?
Responsabilité : Qui fait quoi?
ROI : Combien ça coute ?
Infrastructure de test
Processus d’automatisation
Conclusion
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
Accélérer les tests d’acceptation avec un DSL et du refactoringLaurent PY
Le pilotage des développements par les tests d’acceptation reste un problème difficile à maîtriser dans les projets agiles. D’une part, il est compliqué d’impliquer les analystes métier dans la réalisation de scripts de tests automatisés, et d’autre part les tests de hauts niveaux qu’ils peuvent produire sont souvent difficiles à maintenir et automatiser.
L’approche proposée, supportée par une plate-forme appelée Zest, associe la définition des scénarios de tests d’acceptation sur la base d’un DSL (Domain-Specific Language) construit incrémentalement avec des mots d’action, et des fonctions de refactoring qui permettent en permanence d’optimiser les scénarios pour en faciliter l’automatisation et leur maintenance.
L’université de la performance vous fera découvrir comment concevoir la plus grosse fonctionnalité implicite d’une application: Sa performance.
Pour cela nous vous proposerons une démarche en trois étapes: - Connaître les différents types de tests de charge et savoir quand les utiliser - Mettre en place un test de charge et des outils nécessaires pour le monitoring - Savoir identifier et optimiser les différents goulets d’étranglement de l’application
Le tout mis en pratique sur une application réelle.
Similaire à La qualité au meilleur prix grâce aux tests unitaires (20)
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)
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.
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)
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é
68. Merci de votre attention !
Twitter
= @gdelamarre
Mail
= gauthier.delamarre@
vaconsulting.lu
Notes de l'éditeur
«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