De même, lié à des problèmes de gestionnaire de fenêtre, la gestion native du driver de Firefox (native events) n'est pas activée par défaut sur Linux. C'est donc la gestion "synthétique" qui est utilisée (synthetic events). À savoir l'injection de JavaScript. Ce qui empêche l'utilisation de l'API des interactions utilisateurs avancés (drag-N-drop & co) car elle est mal supportée avec les événements synthétiques. Et la maintenance de cette gestion native par le passé pour Firefox a introduit des régressions.
Pour le cas des tests Cooperons! les problématiques rencontrées sont les mêmes décrites au début de l’article en plus d’une autre particularité : On a besoin d’effectuer des mises en production fréquentes et livrer de nouvelles releases sur des intervalles rapprochés (parfois d’une façon hebdomadaire). Sachant que l’exécution de tout le cahier de test est effectuée par 3 testeurs/développeurs et nécessite entre 4 et 5 jours pour être finalisée. On a fini avec des deadlines non respectés et un processus de test plus lent et moins fiable. L’automatisation s’impose dans un tel cas. Les résultats obtenus sur Coopérons! grâce à l’automatisation ont permis de :
                                                                                                                                                                                                                                                                                                                                                                                 

Un certain logiciel testant des tâches, comme le test de régression d'interface à bas niveau vaste, peut être laborieux et consommateur de temps pour le faire manuellement. De plus, une approche manuelle ne pourrait pas toujours être efficace dans la découverte des certaines classes de défauts. L'automatisation de test offre une possibilité d'exécuter ces types de tests efficacement. Une fois les tests automatisés ont été développés, ils peuvent être exécutés rapidement et à plusieurs reprises. Plusieurs fois, ceci peut être une méthode rentable pour le test de régression des produits logiciels qui ont une longue vie de maintenance. Même des pièces mineures sur la durée de vie de ll'application peuvent ne causer que des fonctions existantes se cassent qui travaillait à un moment précédent.

Lors de la création d’un test, l’outil dispose généralement d’un pointeur d’objets qui met en avant l’objet situé sous le pointeur de la souris. La reconnaissance de cet objet passe par la comparaison de ses propriétés à celles des objets ou types d’objets présents dans le référentiel. Si la correspondance entre l’objet pointé et celui du référentiel est forte, il est alors possible de définir avec une grande probabilité que l’objet pointé est du même type que celui du référentiel.

PhantomJS va nous servir de "Web-Driver" et cela sera là son unique utilité. De quoi s'agit-il ? Afin que Python puisse interagir avec le navigateur Web (Chrome, Firefox ou autres), de la même manière que la communication avec une base de données, il nous faut un driver (pilote). C'est là qu'intervient le Web Driver, il permet la communication entre le navigateur Web et notre script Python. De base, Selenium peut utiliser différents drivers pour différents navigateurs (Chrome, Firefox, Opéra) mais ce qui nous intéresse, ce n'est pas d'ouvrir un navigateur mais d'avoir un navigateur headless (sans interface graphique, uniquement en ligne de commandes). C'est là qu'intervient PhantomJS, qui fournit lui-même son Web Driver. L'utilité c'est donc la rapidité d'exécution par rapport aux navigateurs classiques. 
×