Etape critique d'un projet de développement, le test passe par la mise en œuvre de méthodes et d'outils particuliers. Vous avez été amené à construire une plate-forme dans cette optique.

Participez

Tests : unitaires - web - flux, en continues

Jonathan Le Gloahec , Rennes le 02 janvier 2009

Comment votre environnement a-t-il été construit. Sur quels technologies et outils particuliers repose-t-il ?

Ubiflow est une plateforme de
multidiffusion d'annonces classées sur Internet. La solution est architecturée autour d'un framework «maison» adapté à notre métier sur une plateforme lamp.
Pour tester l'ensemble des fonctionnalités les tests automatisés se sont imposés à nous.
Quelque soit le type de test effectué, les sources à tester étant en php, nous utilisons
Simpletest, pour effectuer les tests et pour afficher / enregistrer les résultats.
Tous les tests sont automatisés.
Nous utilisons Subversion pour la gestion de nos sources.
Conformément aux bonnes pratiques, le tronc de l'application est réputé stable et déployable à tout moment. C'est donc ce tronc qui est testé en continu.
Les tests unitaires sont lancés
deux fois par jour à partir d'un serveur linux.
Les tests fonctionnels (interfaces web)
sont effectués par un PC «automate»
piloté par Selenium-rc une fois par jour. Enfin, les tests des flux d'annonces
(imports / exports), propres à notre métier, sont
regroupés avec les tests unitaires.

Pouvez-vous nous décrire votre méthode de test ?

Nous avons un projet dédié aux tests, qui n'est autre que le reflet de l'application principale, géré également dans Subversion.
Chaque développeur possède
sa version locale du projet de test qu'il exécute, enrichit, adapte et valide en même temps que son développement.
Une fois validé, le tout est livré dans les projets svn respectifs.
Le serveur de test quant à lui, se met systématiquement le head (dernière version svn) du tronc et des tests au début de son exécution.

Quelles sont les principales difficultés de ce travail ?

Les possibles différences entre
l'environnement de développement et l'environnement de production, pouvant créer des différences de réaction pour un même test (le test fonctionne en local, mais pas sur le
serveur de test). Il faut prévoir souvent des adaptions des configurations locales (sous Windows), ou au pire, des hacks pour
contourner ces différences. Bien heureusement, nous n'avons pas souvent recours à ce genre de pratiques.

Signaler un abus