Lu sur le web :
L’utilité des tests fonctionnels pour les applications web n’est plus à démontrer (comment ça, vous ne testez pas encore vos apps ?). Malheureusement, tout ne peut pas être totalement testé fonctionnellement, ou de façon aisée : je pense par exemple au player chez nous, un composant stratégique mais pauvrement testé fonctionnellement de par sa nature un peu hybride (mélange de flash et de JS). Dans tous les cas, pour ce qui peut l’être, nous sommes partisans dans l’équipe Cytron d’user sans mesure (ou presque !) de cet outil de manière à être le plus zen possible au moment d’appuyer sur le bouton “deploy”.
Intéressant, mais à deux moments j’ai l’impression de tâtonnements, de tests qui peuvent échouer sans raisons et qu’on relance pour s’assurer que ça passe. Je trouve ça assez risqué comme approche. Ai-je mal compris ?
il nous arrivait que le comportement “hover” ne soit pas déclenché, mettant en échec la suite du test. Nous avons donc changé notre manière d’effectuer le rollover : on répète l’action grâce au
waitUntiltant que l’élement devant apparaître au hover n’est pas visible
Pourquoi l’événement n’est-il pas déclenché ? Et l’utilisateur risque-t-il d’avoir le même bug ?
Elle permet de stocker dans un fichier texte la liste des scénarios en échec pour les relancer ensuite afin de vérifier qu’ils le sont réellement.
Des faux positifs ? Et si parfois le test échoue alors qu’il ne devrait pas, il y a-t-il un risque qu’il réussisse alors qu’il ne devrait pas ? Combien de fois le relancer pour être certain du résultat ?
Le retour d’expérience est extrêmement intéressant, mais ça laisse un goût de bidouille qu’il serait préférable de corriger avant de considérer la solution comme stable.