Discussion :

[chokrov]

Salut les gens .
Je voudrais automatiser les tests qui se déroulent sur une application web basée sur ExtJS .
Je sais qu'il y'a des outils de tests unitaires comme Jasmine mais en fait je ne pense pas que ce genre d'outils et ce genre de concepts peut dépanner car je considère que la programmation ExtJs est une programmation fortement évennementielle (click par ci , double clic par là etc .. ) et ces outils de tests unitaires ont l'air d'être déstinés au tests des fonctions , bref je pense que ce genre d'outils simule très mal l'intéraction avec les composants graphiques .
Pouvez vous m'éclairer ? Je pense qu'il existe des outils qui peuvent enregistrer les tests qu'on fait sur le naviguateur en capturant les différentes séquences de tests pour les reproduire à la demande . Pouvez vous m'égouiller et me dire si cette piste peut déboucher sur quelque chose de bien ?

Merci d'avance .

[sekaijin]

Cela n'est pas propre à JavaScript, mais à toutes les technos pour faire des IHM

il existe effectivement des outils pour simuler les clicks, Drag, etc.
En 30 ans, je n'ai jamais trouvé d'outil suffisamment bien fait pour envisager de tester de façon automatique les applis.

Souvent, ces outils aident partiellement à tester des parties de l'IHM.
Mais finalement, je constate depuis longtemps que les entreprises qui automatisent le plus les tests le font sur la base des tests unitaires, tests fonctionnels (métier), tests d'intégration technique (APIs, Réseaux... interactions avec l'environnement). Mais la plupart du temps l'IHM est, elle, testée par des Humains.

Pour avoir pratiqué des tests de ce genre dans ma carrière, la principale difficulté est l'écriture du test.
Souvent, on pense qu'en enregistrant les actions de l'utilisateur on va pouvoir produire un scénario
C’est totalement faux. On n'obtient qu'une séquence. Un test c'est plus que ça. du coup, on fait l'action à la main
On récupère la séquence d'événements et on la modifie, car ce n'est jamais parfait. On crée l'environnement, le contenu métier, etc. Et on écrit ce qu'on attend du test.

Lorsqu'on a fait tout ça, on peut jouer la campagne de test. Et on a alors les résultats. Mais il reste toujours une partie qu'on ne peut pas tester de la sorte.

Cela n'empêche pas de devoir, à l'avance, spécifier les tests, c'est à dire définir les scénarii les environnements les données, et les résultats attendus.

On pense souvent lorsqu'on envisage ce genre de chose qu'on va gagner la possibilité de rejouer ces tests.

Mais par expérience, une variation minime dans un fichier CSS par exemple peut entrainer l'obsolescence de l'ensemble.

Au final, j'ai fini par constater que je ne gagnais pas grand-chose. Chaque évolution de l'appli impliquait de réécrire quasi tous les tests. Et pour les réécrire le plus souvent il faut repartir de zéro. Rares sont les cas où il suffit de modifier un test.

quand on fait le bilan, on a deux façons de faire auto ou manuel
et si on compare
en manuel, on a :
définition des tests
préparation des environnements
exécution manuelle des tests
rédaction des résultats

en auto, on a :
définition des tests
préparation des environnements
exécution manuelle des tests
récupération des scripts
Modification des scripts
Remise en état des environnements
Passage des tests automatisé
passage des tests non automatisable
rédaction des résultats

On voit vite que lorsqu'on automatise on fait quasi 100% de ce qu'on fait en manuel plus tout un tas d'autres trucs.

Depuis longtemps, je ne fais plus de tests d'IHM avec des simulateurs de click et autre truc.
Je crée des bouchons d'IHM. par exemple sur un bouton je récupère dans un objet de test le binding.
Ensuite je ne simule pas le click, mais j'appelle le la méthode.

je ne suis donc plus dépendant de la position du bouton dans l'IHM
De plus si la méthode du binding est accessible de plusieurs points d'IHM (bouton, menu, click-droit, etc.) je n'ai qu'un appel à faire.

Par contre, cette façon de faire a un gros inconvénient : on injecte le code du test dans l'appli.
L’idéal serait de créer un plug-in chrome ou ff qui permette d'injecter le test dans le document sans intervenir sur l'appli.

A+JYT

[ascito]

moi je pense que :

les générateurs de tests unitaires pour javascript, sont... écris en javascript...

donc je fais tout de même plus confiance à mes propres tests qu'aux tests créés par un tiers qui simuleraient des choses sans en connaitre la forme.