Contao CMS Open Source

[synergie]

Bonjour,

J'utilise actuellement NetBean's et le projet de PHPUnit pour réaliser des tests unitaires dans les modules Contao que je réalise.

C'est très facile d'en faire sur des nouveaux objets que je réalise dans d'autre projet, par contre sur les pages de code de Contao comme les DCA etc... contient toujours : "<?php if (!defined('TL_ROOT')) die('You can not access this file directly!');" pour des raisons de sécurité, ce qui ne permet pas à la page d'être appelé par les UnitTests. Il est nécessaire de mettre cette ligne sur toutes les entités hormis bien entendu les templates.

Est il possible de passe outre cette protection pour appeler les tests unitaires? quel est la best practice des tests dans les modules Contao?

Merci

[cyril]

Et si tu définit le chemin vers l'installation de Contao dans ton script de test ? ex : define('TL_ROOT', 'chemin d'install de Contao');

[synergie]

pas bête effectivement ça fonctionne.

[oelmekki]

En voilà un sujet intéressant :)

Je m'y suis également confronté, mais j'ai utilisé phpspec plutôt que PHPUnit et cucumber.

Alors déjà, concernant les best pratices, c'est simple : les dévs contao ne testent pas leur code :]

Si tu veux des pistes pour résoudre des problèmes auxquels je me suis peut-être déjà confronté, tu peux jeter un oeil à mon extension testing. C'est très bordélique et donc pas fait pour être distribué (je doute que quelqu'un d'autre que moi puisse s'en servir), mais peut-être cela pourra t'aider.

Les principaux problèmes que j'ai rencontrés sont la distinction entre base de donnée prod et base de donnée test (il ne faut pas que tes tests pourrissent ta base de donnée courante), l'utilisation par typolight de __autoload() (alors que phpspec utilise spl_autoload, je suppose que PHPUnit fait de même) et le fait qu'un module, pour être initialisé, demande une entrée de base de donnée de tl_module.

Pour résoudre tout cela, voici comment j'ai procédé.

D'abord, j'ai fait une copie de system/initialize.php. Ce fichier est chargé en premier dans chaque process de test et initialise contao (tu n'as ainsi pas le problème du if ! defined( TL_ROOT), ni de l'absence de tout ce qui est initialisé d'habitude ). Par rapport à l'original, __autoload y est remplacé par spl_autoload, de manière à permettre au framework de test de mettre ce qu'il veut en autoload.

C'est dans ce fichier aussi que je fais changer la db. Personnellement, j'ai opté pour un fichier de config en .yml dans lequel je met les infos de db. Les paramètres de connexion dans $GLOBALS sont changés à cette occasion pour switcher de la db principale vers la db de test.

Il faut également un moyen de démarrer les tests sur une base de donnée "propre". Il te faut pour ça générer un dump que tu chargeras avant de lancer ta batterie de test. Si tu as une autre solution, je suis prenneur, parce que ça ralentit beaucoup l'ensemble :) J'ai implémenté des rollbacks, à une époque (il faut pour ça changer le type de chaque table parce que MyISAM ne les gère pas, et tl_search pose pb à cause de son FULLTEXT qui n'est pas géré par InnoDb), je ne me souviens plus trop pourquoi je les ai abandonné, à vrai dire :P

Enfin, pour pouvoir faire new ModuleQuelchose(), il faut que tu lui passes un Database_Result en paramètre. C'est assez ennuyeux, surtout si tu fais du behaviour/test driven development et que ton module n'a encore aucune entrée dans la base de donnée. J'ai sous-classé Database_Result pour résoudre ce problème. Il suffit donc de faire un new ModuleQuelqueChose( new FakeModuleDbResult() ).

[synergie]

Alors déjà, concernant les best pratices, c'est simple : les dévs contao ne testent pas leur code :]

HaHaaaaa !

Bravo voici enfin la première ressource digne de ce nom!

Effectivement pour la base de données il faudrait implémenter des "Mock objects" qui répondent de la même manière sans utiliser la db ou il y a aussi des tests qui fond un rollback par la suite des actions. C'est moins propre de remplir la db mais cette approche est plus proche de la réalités et permet de tester aussi la base.

En tout cas merci pour ta réponse, il me faut maintenant du temps pour digérer ton module.

[oelmekki]

Oui désolé, il est franchement indigiste :P Surtout qu'il y a un peu de php, un peu de ruby, xxx dépendances, que ca fait du test de spec, de user stories via selenium, de la continuous intégration,etc. Désolé d'avance ^^

Pour les mocks, c'était ma principale raison pour ne pas utiliser PHPUnit, parce qu'il ne permet pas de stubber l'instanciation d"un objet (comme par exemple en ruby avec rspec, ou on peut faire : MyClass.should_receive( :new ).and_return( @quelquechose ) ).

J'ai fais une classe de mocking mais ce n'est pas suffisant dans le cas de contao parce que la structure du site est entièrement mise dans la base de donnée. C'est vrai que ce n'est pas trop un problème pour les tests unitaires et les tests fonctionnels ; ça l'est nettement plus pour les tests d'intégration.