Tests unitaires et fonctionnels avec Symfony

Titre présentation | Conférencier

Tests unitaires et fonctionnels avec Symfony 1.2

Geoffrey Bachelet - Hugo Hamon

vendredi 12 juin 2009

Tests unitaires et fonctionnels | Geoffrey Bachelet - Hugo Hamon

Qui sommes-nous ?

• Geoffrey Bachelet • Hugo Hamon



Au sommaire...

• Introduction aux tests automatisés

• Les tests unitaires

• Les tests fonctionnels

• Introduction à l’intégration continue



Introduction aux tests automatisés



Introduction aux tests automatisés

• 2 sortes : unitaires et fonctionnels (recette)

• Intégrés dans les méthodes agiles (XP)



Ils sont les garants...

• du bon fonctionnement du code,• sa robustesse,• sa maintenabilité,• son évolutivité,• sa pérennité,

• de la qualité globale du code / application



Les tests unitaires



Définition

« En programmation informatique, le test unitaire est un procédé permettant de s’assurer du fonctionnement correct d’une partie déterminée d’un logiciel ou d’une portion d’un programme »

Wikipédia



La règle F.I.R.S.T

• Fast

• Independant

• Repeatable

• Self-Validating

• Timely



Les avantages

• valider le fonctionnement

• éviter les régressions fonctionnelles

• découvrir des bugs

• faciliter le refactoring



Les avantages

• documenter le code

• faciliter les migrations

• structurer le développement

• rentabiliser à moyen terme



Avoir confiance en son code !



Les contraintes

• les tests sont coûteux !

• savoir tester l’essentiel

• maintenir la suite de tests à 100%

• écrire des tests en permanence



Les contraintes

Les tests impliquent de la rigueur !



Quand tester du code ?

• avant l’implémentation (TDD)• après l’implémentation• à la correction d’un bug

• tester continuellement est la clé !



Que faut-il tester ?

• les classes du modèle (classes et méthodes)• les bibliothèques utilisateurs (fonctions)• les inclusions de fichiers

• Ne pas tester du code déjà testé !



Ayez une approche pragmatique !



L’approche pragmatique

• tester les méthodes et fonctions critiques

• tester quand un bug est découvert

• => peu de tests valent toujours mieux que rien !



Les outils de test en PHP

SnapTest

Testilence

Lime



Lime

• Adaptation du module Perl Test::More

• Conforme au standard Test Anything Protocol

• API simple et testée

• Exécute les tests dans des processus séparés



Test Anything Protocol

• Créé en 1987

• Procédure de standardisation IETF (2008)

• Basé sur le module Perl Test::Harness

• Spécification de-facto

• Format de sortie des tests standardisé



L’environnement de test

• Il doit être unique

• Réinitialisé pour chaque suite de tests

• Différent de l’environnement de production !!!



Les fichiers YAML



Les données de test : fixtures

• Chargées en BDD à chaque exécution

• Fichiers YAML dans test/fixtures• 1 fichier par modèle• Fichiers préfixés par un numéro



Le répertoire test/fixtures



Exécuter des suites de tests

• php symfony test:all

• php symfony test:unit

• php symfony test:unit testFile

• php symfony test:functional frontend

• php symfony test:functional frontend testFile

• php test/unit/testFileTest.php

• php test/functional/frontend/testFileTest.php



Exemple pratique (TDD)

Tester une méthode de classe



Le modèle Product



Le modèle ProductLine



Tester la méthode getTotalPrice()



Tester la méthode getTotalPrice()



Un bug est découvert...



Le test confirme le bug !



Correction du bug



Validation par les tests



Tester des objets Doctrine



Tester des objets Doctrine



Les objets Mock

• Simuler une fonctionnalité

• S'abstraire du contexte réel (webservices, bases de données, système de fichiers)

• S'abstraire des dépendances



Les objets Mock - Exemple 1

• Fixation des droits d’accès de l’utilisateur




• Simuler une fonctionnalité






Quelques pièges à éviter...

• sfContext

• sfConfig

• Dépendances dures



sfContext dans le modèle









sfConfig dans le modèle









La couverture de code

• Requiert l’extension xdebug

• apt-get install php5-xdebug

• pecl install xdebug

• http://pecl.php.net/package/Xdebug


http://pecl.php.net/package/Xdebug

http://pecl.php.net/package/Xdebug


La couverture de code

• Par bibliothèque

• symfony test:coverage test/unit lib/

• symfony test:coverage test/unit/myLibTest.php lib/myLib.php

• Par projet

• symfony test:coverage test/ .



Les tests fonctionnels



Objectif des tests fonctionnels

• Tester les fonctionnalités de l’application

• Introspecter tous les objets du framework

• Documenter un scénario d’utilisation



Les limites des tests fonctionnels

• Limités à l’environnement Symfony,

• Les JavaScript ne sont pas testables,

• Ne permettent pas de tester le rendu «visuel»,

• Ne remplacent pas des tests Sélénium



L’objet sfBrowser

• Simule le comportement d’un navigateur web

• Rend les objets du framework disponibles de la requête à la réponse

• Ne nécessite pas de serveur web

• Embarque lime



Configurer le navigateur de test

setHttpHeader() Fixe un en-tête HTTP

setAuth() Définit les droits d’accès basiques

setCookie() Fixe un cookie

removeCookie() Supprime un cookie

clearCookies() Supprime tous les cookies courants

followRedirect() Suit la redirection déclenchée



Simuler la navigation

get() Simule une requête GET

post() Simule une requête POST

call() Simule une requête PUT ou DELETE back() Retourne à la page précédente de l’historique de navigation

forward() Avance d’une page dans l’historique de navigation

reload() Recharge la page courante

click() Simule un clic sur un lien ou un bouton de formulaire

select() Sélectionne un bouton radio ou une case à cocher

deselect() Désélectionne un bouton radio ou une case à cocher

restart() Réinitialise tous les paramètres du navigateur



• Embarque sfBrowser

• API fluide et lisible

• Extensible

• Délègue les tests aux «testeurs»

L’objet sfTestFunctional



Une API fluide et lisible



Une API extensible - Exemple 1









Les blocs de tests



Les objets testeurs

• sfTesterRequest• sfTesterResponse (CSS 3 selectors - xPath en symfony 1.3)• sfTesterForm• sfTesterUser• sfTesterViewCache

• sfTesterDoctrine• sfTesterPropel



Créer des objets testeurs









Tests dans les plugins




• sfTaskExtraPlugin

– http://www.symfony-project/plugins/sfTaskExtraPlugin– Créé par Kris Wallsmith (core team)

• symfony generate:plugin sfMyPlugin

– Structure de base du plug-in– Bootstraps de tests– Fixtures pour les tests fonctionnels


http://www.symfony-project/plugins/sfTaskExtraPlugin

http://www.symfony-project/plugins/sfTaskExtraPlugin



• php symfony test:plugin sfFooPlugin

• php symfony test:plugin --only=unit sfFooPlugin

• php symfony test:plugin --only=functional sfFooPlugin



Tests unitaires vs Tests de recette



Introduction à l’intégration continue

• Exécution des tests

• Rapport d’erreur

• Build du projet

• Automatique !



L’intégration continue - Pourquoi ?

1.Contrôler les régressions

2.Valider les fonctionnalités



L’intégration continue

• Les régressions

– corrigées par les développeurs

• Les fonctionnalités

– vérifiées par le client



L’intégration continue - Outils

• CruiseControl (Java)

• Hudson (Java)

• Xinc (PHP)

• phpUnderControl (PHP)

• symfonyUnderControl (phpUnderControl)

• sismo



sismo

• Développé par Fabien Potencier• http://ci.symfony-project.org/


http://ci.symfony-project.org



sismo

• Développé par Fabien Potencier• http://ci.symfony-project.org/





Merci !

Des questions ?


Technology

Tests unitaires et fonctionnels avec Symfony