[Lecture] On a testé fonc­tion­nel­le­ment notre app JS


Lu sur le web :

L’uti­lité des tests fonc­tion­nels pour les appli­ca­tions web n’est plus à démon­trer (comment ça, vous ne testez pas encore vos apps ?). Malheu­reu­se­ment, tout ne peut pas être tota­le­ment testé fonc­tion­nel­le­ment, ou de façon aisée : je pense par exemple au player chez nous, un compo­sant stra­té­gique mais pauvre­ment testé fonc­tion­nel­le­ment 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 parti­sans dans l’équipe Cytron d’user sans mesure (ou presque !) de cet outil de manière à être le plus zen possible au moment d’ap­puyer sur le bouton “deploy”.

chez M6 Web

Inté­res­sant, mais à deux moments j’ai l’im­pres­sion de tâton­ne­ments, de tests qui peuvent échouer sans raisons et qu’on relance pour s’as­su­rer que ça passe. Je trouve ça assez risqué comme approche. Ai-je mal compris ?

il nous arri­vait que le compor­te­ment “hover” ne soit pas déclen­ché, mettant en échec la suite du test. Nous avons donc changé notre manière d’ef­fec­tuer le rollo­ver : on répète l’ac­tion grâce au waitUntil tant que l’éle­ment devant appa­raître au hover n’est pas visible

Pourquoi l’évé­ne­ment n’est-il pas déclen­ché ? Et l’uti­li­sa­teur risque-t-il d’avoir le même bug ?

Elle permet de stocker dans un fichier texte la liste des scéna­rios en échec pour les relan­cer ensuite afin de véri­fier qu’ils le sont réel­le­ment.

Des faux posi­tifs ? Et si parfois le test échoue alors qu’il ne devrait pas, il y a-t-il un risque qu’il réus­sisse alors qu’il ne devrait pas ? Combien de fois le relan­cer pour être certain du résul­tat ?

Le retour d’ex­pé­rience est extrê­me­ment inté­res­sant, mais ça laisse un goût de bidouille qu’il serait préfé­rable de corri­ger avant de consi­dé­rer la solu­tion comme stable.

,

2 réponses à “[Lecture] On a testé fonc­tion­nel­le­ment notre app JS”

  1. Bonjour,

    Merci pour ces quelques notes.

    Je suis totalement d’accord sur le terme « bidouille » mais je n’ai (de mon expérience personnelle) jamais rencontré de systèmes de tests fonctionnels parfaitement stables, ni en JS ni en PHP. D’ailleurs, si les frameworks intègrent la fonctionnalité « rerun », c’est qu’il y a une raison… Cependant, s’il y a des risques qu’un test ne passe pas alors qu’il devrait, l’inverse n’est pas vrai si on écrit ses tests correctement (vérifier l’absence d’un élément peut être bancal si c’est la seule assertion), le problème étant lié au fait que le système utilisé n’arrive parfois pas à réaliser l’action demandée dans le browser.

    Dans tous les cas, cette stack, telle quelle, nous est forte utile au quotidien et nous a sauvé de nombreuses fois de regressions difficilement détectables.

    A disposition pour échanger.

    Florent

    • Oh, je ne doute pas de l’utilité de la chose. Je suis convaincu de l’utilité des tests navigateur et je n’ai vu aucune boite satisfaite de ce qu’elle a (et la plupart en sont effectivement au niveau de la bidouille)

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.