Le coeur de SimpleTest est un framework de test construit autour de classes de scénarios de test. Celles-ci sont écrites comme des extensions des classes premières de scénarios de test, chacune élargie avec des méthodes qui contiennent le code de test effectif. Les scripts de test de haut niveau invoque la méthode run() à chaque scénario de test successivement. Chaque méthode de test est écrite pour appeler des assertions diverses que le développeur suppose être vraies, assertEqual() par exemple. Si l'assertion est correcte, alors un succès est expédié au rapporteur observant le test, mais toute erreur déclenche une alerte et une description de la dissension.
Un scénario de test ressemble à...
class MyTestCase extends UnitTestCase {
function testLog() {
$log = &new Log('my.log');
$log->message('Hello');
$this->assertTrue(file_exists('my.log'));
}
}
Ces outils sont conçus pour le développeur. Les tests sont écrits en PHP directement, plus ou moins simultanément avec la construction de l'application elle-même. L'avantage d'utiliser PHP lui-même comme langage de test est qu'il n'y a pas de nouveau langage à apprendre, les tests peuvent commencer directement et le développeur peut tester n'importe quelle partie du code. Plus simplement, toutes les parties qui peuvent être accédées par le code de l'application peuvent aussi être accédées par le code de test si ils sont tous les deux dans le même langage.
Le type de scénario de test le plus simple est le UnitTestCase. Cette classe de scénario de test inclut les tests standards pour l'égalité, les références et l'appariement de motifs (via les expressions rationnelles). Ceux-ci testent ce que vous seriez en droit d'attendre du résultat d'une fonction ou d'une méthode. Il s'agit du type de test le plus commun pendant le quotidien du développeur, peut-être 95% des scénarios de test.
La tâche ultime d'une application web n'est cependant pas de produire une sortie correcte à partir de méthodes ou d'objets, mais plutôt de produire des pages web. La classe WebTestCase teste des pages web. Elle simule un navigateur web demandant une page, de façon exhaustive : cookies, proxies, connexions sécurisées, authentification, formulaires, cadres et la plupart des éléments de navigation. Avec ce type de scénario de test, le développeur peut garantir que telle ou telle information est présente dans la page et que les formulaires ainsi que les sessions sont gérés comme il faut.
Un scénario de test web ressemble à...
class MySiteTest extends WebTestCase {
function testHomePage() {
$this->get('http://www.my-site.com/index.php');
$this->assertTitle('My Home Page');
$this->clickLink('Contact');
$this->assertTitle('Contact me');
$this->assertWantedPattern('/Email me at/');
}
}
Ci-dessous vous trouverez un canevas assez brut des fonctionnalités à aujourd'hui et pour demain, sans oublier leur date approximative de publication. J'ai bien peur qu'il soit modifiable sans pré-avis étant donné que les jalons dépendent beaucoup sur le temps disponible. Les trucs en vert ont été codés, mais pas forcément déjà rendus public. Si vous avez une besoin pressant pour une fonctionnalité verte mais pas encore publique alors vous devriez retirer le code directement sur le CVS chez SourceFourge. Une fonctionnalitée publiée est indiqué par "Fini".
| Fonctionnalité | Description | Publication |
|---|---|---|
| Scénariot de test unitaire | Les classes de test et assertions de base | Fini |
| Affichage HTML | L'affichage le plus simple possible | Fini |
| Autochargement des scénarios de test | Lire un fichier avec des scénarios de test et les charger dans un groupe de tests automatiquement | Fini |
| Générateur de code d'objets fantaisie | Des objets capable de simuler d'autres objets, supprimant les dépendances dans les tests | Fini |
| Bouchons serveur | Des objets fantaisie sans résultat attendu à utiliser à l'extérieur des scénarios de test, pour le prototypage par exemple. | Fini |
| Intégration d'autres testeurs unitaires | La capacité de lire et simuler d'autres scénarios de test en provenance de PHPUnit et de PEAR::Phpunit. | Fini |
| Scénario de test web | Appariement basique de motifs dans une page téléchargée. | Fini |
| Analyse de page HTML | Permet de suivre les liens et de trouver la balise de titre | Fini |
| Simulacre partiel | Simuler des parties d'une classe pour tester moins qu'une classe ou dans des cas complexes. | Fini |
| Gestion des cookies Web | Gestion correcte des cookies au téléchargement d'une page. | Fini |
| Suivi des redirections | Le téléchargement d'une page suit automatiquement une redirection 300. | Fini |
| Analyse d'un formulaire | La capacité de valider un formulaire simple et d'en lire les valeurs par défaut. | Fini |
| Interface en ligne de commande | Affiche le résultat des tests sans navigateur web. | Fini |
| Mise à nu des attentes d'une classe | Peut créer des tests précis avec des simulacres ainsi que des scénarios de test. | Fini |
| Sortie et analyse XML | Permet de tester sur plusieurs hôtes et d'intégrer des extensions d'acceptation de test. | Fini |
| Scénario de test en ligne de commande | Permet de tester des outils ou scripts en ligne de commande et de manier des fichiers. | Fini |
| Compatibilité avec PHP Documentor | Génération automatique et complète de la documentation au niveau des classes. | Fini |
| Interface navigateur | Mise à nu des niveaux bas de l'interface du navigateur web pour des scénarios de test plus précis. | Fini |
| Authentification HTTP | Téléchargement des pages web protégées avec une authentification basique seulement. | Fini |
| Boutons de navigation d'un navigateur | Arrière, avant et recommencer | Fini |
| Support de SSL | Peut se connecter à des pages de type https. | Fini |
| Support de proxy | Peut se connecter via des proxys communs | Fini |
| Support des cadres | Gère les cadres dans les scénarios de test web. | Fini |
| Test de l'upload de fichier | Peut simuler la balise input de type file | 1.0.1 |
| Amélioration sur la machinerie des rapports | Retouche sur la transmission des messages pour une meilleur coopération avec les IDEs | 1.1 |
| Amélioration de l'affichage des tests | Une meilleure interface graphique web, avec un arbre des scénarios de test. | 1.1 |
| Localisation | Abstraction des messages et génration du code à partir de fichiers XML. | 1.1 |
| Simulation d'interface | Peut générer des objets fantaisie tant vers des interfaces que vers des classes. | 2.0 |
| Test sur es exceptions | Dans le même esprit que sur les tests des erreurs PHP. | 2.0 |
| Rercherche d'éléments avec XPath | Peut utiliser Tidy HTML pour un appariement plus rapide et plus souple. | 2.0 |
Ressources sur le web pour les tests
Le processus est au moins aussi important que les outils. Le type de procédure que fait un usage le plus intensif des outils de test pour développeur est bien sûr l'Extreme Programming. Il s'agit là d'une des méthodes agiles qui combinent plusieurs pratiques pour "lisser la courbe de coût" du développement logiciel. La plus extrème reste le développement piloté par les tests, où vous devez adhérer à la règle du pas de code avant d'avoir un test. Si vous êtes plutôt du genre planninficateur ou que vous estimez que l'expérience compte plus que l'évolution, vous préférerez peut-être l'approche RUP. Je ne l'ai pas testé mais je peux voir où vous aurez besoin d'outils de test (cf. illustration 9).
La plupart des testeurs unitaires sont dans une certaine mesure un clone de JUnit, au moins dans l'interface. Il y a énormément d'information sur le site de JUnit, à commencer par la FAQ quie contient pas mal de conseils généraux sur les tests. Une fois mordu par le bogue vous apprécierez sûrement la phrase infecté par les tests trouvée par Eric Gamma. Si vous êtes encore en train de tergiverser sur un testeur unitaire, sachez que les choix principaux sont PHPUnit et Pear PHP::PHPUnit. De nombreuses fonctionnalités de SimpleTest leurs font défaut, mais la version PEAR a d'ores et déjà été mise à jour pour PHP5. Elle est aussi recommandée si vous portez des scénarios de test existant depuis JUnit.
Les développeurs de bibliothèque n'ont pas l'air de livrer très souvent des tests avec leur code : c'est bien dommage. Le code d'une bibliothèque qui inclut des tests peut être remanié avec plus de sécurité et le code de test sert de documentation additionnelle dans un format assez standard. Ceci peut épargner la pêche aux indices dans le code source lorsque qu'un problème survient, en particulier lors de la mise à jour d'une telle bibliothèque. Parmi les bibliothèques utilisant SimpleTest comme testeur unitaire on retrouve WACT et PEAR::XML_HTMLSax.
Au jour d'aujourd'hui il manque tristement beaucoup de matière sur les objets fantaisie : dommage, surtout que tester unitairement sans eux représente pas mal de travail en plus. L'article original sur les objets fantaisie est très orienté Java, mais reste intéressant à lire. Etant donné qu'il s'agit d'une nouvelle technologie il y a beaucoup de discussions et de débats sur comment les utiliser, souvent sur des wikis comme Extreme Tuesday ou www.mockobjects.comou the original C2 Wiki. Injecter des objets fantaisie dans une classe est un des champs principaux du débat : cet article chez IBM en est un bon point de départ.
Il y a énormement d'outils de test web mais la plupart sont écrits en Java. De plus les tutoriels et autres conseils sont plutôt rares. Votre seul espoir est de regarder directement la documentation pour HTTPUnit, HTMLUnit ou JWebUnit et d'espérer y trouver pour des indices. Il y a aussi des frameworks basés sur XML, mais de nouveau la plupart ont besoin de Java pour tourner.