De l’intérêt de MVC pour tester son application
Quand on utilise une couche d'abstraction de base de données, comme PDO ou n'importe quelle couche écrite en PHP, la raison invoquée est souvent de pouvoir supporter différentes bases de données. Dans la pratique, sauter du jour au lendemain de MySQL à Oracle, ou le contraire, ne se fait jamais aussi simplement. En pratique, c'est même assez fallacieux comme argument.
Communément, il y a une bonne raison pour utiliser une telle couche : faire des tests. Et ça, cela arrive beaucoup plus souvent que de changer de base de données. À l'aide d'un simple changement de configuration, la couche d'abstraction de base de données vous permet de faire tourner facilement votre application sur une base de tests, ou celle de production, ou celle de recette, ou encore de vieilles versions... En disposant de jeux de données de tests, il devient alors possible de reproduire différentes situations, voire même de les faire cohabiter.
C'est une application qui justifie même l'utilisation de MVC de manière pratique : on utilise MVC au quotidien pour pouvoir faire des tests d'une partie de l'application sans perturber l'autre. C'est le principe même de séparation des objectifs.
En fait, la souplesse de la couche d'abstraction est également disponible avec le moteur de gabarits (aussi appelée la vue). Combien d'entre vous se plaignent de devoir envisager d'installer Selenium pour faire tourner des tests sur les gabarits ? C'est long, ça fait peur.
Or, un truc tout simple consiste à utiliser les gabarits pour faire les tests : au lieu de produire une page HTML complexe et pleine de Javascript et de CSS, vous pouvez produire une page XML ou JSON, qui contient toutes les informations à afficher, et dépouillée de la couche de présentation. En fait, n'importe que format facile à analyser dans le cadre de vos opérations sera une bonne idée.
Les tests unitaires deviennent alors beaucoup plus aisés à écrire, et vous ne dépendez plus de la couleur du bouton "OK", ou de la CSS. Vous appelez simplement le site, qui produit une page contenant les informations sans leur présentation. Si les bonnes informations sont présentes, il ne restera plus qu'à tester effectivement les couleurs du site : la logique métier est maintenant sous contrôle.
C'est d'autant plus intéressant que l'on utilise ici les gabarits de deux manières : une pour les tests, et une pour la production. Il manque encore une utilisation tierce des gabarits pour avoir trois utilisations modulaires, et être tranquille quant à la qualité de l'interface modèle / gabarit. Quand on met en place une interface, il faut généralement trois utilisations différentes pour être sûr que l'interface est bien modulaire.
En utilisant MVC pour faire les tests, vous allez gagner beaucoup en qualité de code : d'abord parce que vous allez faire des tests automatisables sur une partie de votre application; ensuite parce que vous allez utiliser la structure de votre application et non plus vous targuer d'utiliser simplement un motif de conception; et aussi comprendre un peu mieux vos différentes interfaces.
Bientôt un plugin PHP pour Sonar
Sonar est un outil Open Source de gestion de la qualité du code. Il analyse le code d'un projet pour fournir de nombreux tableaux de bord qui permettent d'en évaluer la qualité. Pour cela, il utilise différents angles :
- Architecture et conception ;
- Duplications ;
- Test unitaires ;
- Complexité ;
- Bogues potentiels ;
- Règles de codage ;
- Commentaires.
Il possède également un puissant mécanisme d'extensions qui permet de supporter de nouveau langages, d'ajouter des métriques et des règles d'analyse ou encore de s'intégrer au sein d'un processus d'Intégration Continue.
Jusqu'à présent Sonar était très orienté Java et il était impossible d'analyser un projet PHP. Ce temps est en passe d'être révolu grâce à l'arrivée prochaine d'une extension qui permettra d'intégrer les outils liés à l'analyse de la qualité du code qui sont portés depuis le monde Java (PHPUnit, PHP_CodeSniffer, PHP_Depend, etc.)
Cette extension est encore à l'état de prototype mais son potentiel est énorme.
Qu’est-ce qu’industrialiser les développements PHP ?
L'industrialisation des développements PHP est un thème émergent. Depuis quelques mois, on en entend de plus en plus parlé mais qu'est-ce que cela recouvre concrètement ?
Une définition pourrait être que l’industrialisation des développements consiste à mettre en œuvre des pratiques et des outils visant à rendre les logiciels produits plus robustes, tout en restant dans des délais et des coûts maîtrisés. On a donc là deux leviers : des pratiques et des outils qui permettent d'atteindre deux buts précis : obtenir des logiciels robustes en maîtrisant à la fois le budget et le planning.
Ces pratiques et ces outils sont multiples et varient selon les habitudes, les sociétés et les projets. Nous avons tenté d'en lister un certain nombre qui nous paraissent essentiels :
- Former les équipes ;
- Employer une convention de programmation ;
- Utiliser un dépôt de code ;
- Utiliser un framework ;
- Adopter un IDE de développement ;
- Automatiser les tests ;
- Mettre en place une intégration continue ;
- Déployer automatiquement ;
- Pratiquer l'analyse statique ;
- Utiliser des outils de conception ;
- Mettre en place des méthodes de programmation ;
- Maîtriser de la qualité du code ;
- S'assurer de l'implication des utilisateurs.
Et vous, quelles pratiques et outils utilisez-vous pour industrialiser vos développements ?

