Discussion :

[Gallay]

Bonjour,

J'essaye de me mettre aux tests automatiques avec windev. Je trouve que c'est vraiment une usine à gaz qui ne fonctionne pas et je me pose même la question de savoir si il y a un seul développeur au monde qui utilise cette fonctionnalité !
Si vous avez une minute pour me dire votre expérience avec les tests automatiques windev

est ce le produit ou est ce moi le problème

En plus l'aide de windev ca ou rien du tout c'est pareil, si vous avez connaissance d'un tutorial ou de tout autre source d'info qui pourrait m'aider...

merci d'avance

[fdaire]

Pareil pour moi,
j'essaye de m'y mettre mais il semblerait que cela ne fonctionne pas génial!
Par exemple, je ne peux pas reproduire un clic dans une barre de menu classique...
Vous avez du neuf de votre côté?
Merci

[Ry_Yo]

Bonsoir,

Personnellement j'ai testé les "test automatique" avec la version 10 de windev... Il y avait quelque lacune, beaucoup de limitation, mais au final c'était à peu près utilisable pour certain test mais pas tous.... J'ai été obligé de développer à coté une petite appli pour m'aider à reprendre les scripts générer par les "test automatique"...

Avec un peu de patiente et réflexion j'ai contourné les lacunes de la version 10 pour avoir un protocole de test plus performant (pour moi)...

J'ai procédé comme suit :

• le programme à tester est lancé dans une résolution standard 1024*768 et toutes les fenêtres sont maximisées
• j'ai créé des mini-scénario d'action simple (ouvrir fenêtre, selectionner un client, créer une entête de commande, etc...)
• ma petite appli faite maison, me liste mes scénarios et les recomposent et fusionnent à ma guise en un scénario majeur (du style création d'un devis ou alors création d'une fiche client, annulation d'une commande, etc...)
• je modifie la temporisation sur certaine action qui peuvent demander un peu plus de temps fonction de recherche, de gros calcul, de génération de lignes, etc... pour éviter que l'action suivante se déclenche alors qu'un bouton n'est toujours pas actif....

Voilà en gros mon utilisation de l'automate de test... Par contre il est vrai que pour chaque scénario, je partais depuis le lancement de l'application... impossible en version 10 de ne tester qu'une classe, fonction ou procédure...

L'utilisation de la roulette de la souris est interdite.
Les scénarios se basent sur posX et posY de la souris, c'est pour cela qu'un scénario est valide pour une résolution donnée et une taille de fenêtre donnée... si la fenêtre est déplacée, la résolution différente, ça ne marchera plus...

C'est pour cela que sur une autre section du forum j'avais demandé de la documentation pour comprendre comment fonctionne les objets de windows en espérant pouvoir créer mon propre automate de test car étant donné que c'est moi qui code le programme à tester... il est peut-être plus facile de comprendre comment intér-agir avec les objet de windows pour créer un automate de test spécifique à mon application...

Pour mieux comprendre ma pensée.... quand je regarde l'utilitaire de copie d'écran avancé : Fastone capture... il détecte automatiquement, fenêtre, menu, bouton, icone, etc... donc quelque part il reconnait un objet windows... donc je me dis que je peux, peut-être, faire le lien entre l'objet windows et par exemple mon bouton valider et donc déclencher le clic de ce bouton de manière plus précise quelque soit la résolution ou la taille de la fenêtre....

[R&B]

De ce que j'ai vu dans un fichier de scénario, il enregistre les handle et autres joyeusetés Windows pour reproduire le comportement homme dans le projet.

Ainsi on se rapproche de toute les autres solutions de pilotage d'application qui fond nécessairement de même. C'est aussi ce qui explique que les fonctions Pilotexxx ne soient disponibles qu'en mode test.

Enfin, un scenario de test permet de reproduire strictement un comportement précis. J'imagine qu'il faut aussi joindre des bases dans un état précis pour évaluer ces scénarios. C'est sans doute ce qui manque.

Reste que toutes remontés construites au ST devrait a terme nous permettre de voir cet outil s'étoffer et devenir plus maniable.

Au final, le moteur de tests de non regression est, sur le papier, une fort bonne chose. Dans la réalité, c'est un outil qui doit être pris en compte sérieusement dans le processus de développement et demande un fort travail de maquettage des données et de construction/gestion des scénarios.

Dans la pratique, un plus est de le coupler avec du développement spécifique (dispo qu'en mode test) pour préparer le projet au scénario à évaluer.

Le scénario lancera alors ce traitement préparatoire et s'exécute ensuite.

Bref, pas mal de solutions à inventer/prendre en main pour se faciliter la vie.
Evidement, dans la majorité des cas et malheureusement, l'organisation ne permet pas de jouer avec ce genre de choses :soupir:

[Grmmml]

Pour ma part je le trouve complètement inutile (je n'ai pas regardé depuis la 10).
Faire un test ne se limite pas à cliquer sur des boutons pour éventuellement constater que les fenêtre s'ouvrent.

L'important c'est les données ! Et malheureusement, l'outil ne permet aucun contrôle sur celles-ci. Pas d'initialisation des données (BDD, fichiers, flux réseau, ...). Pas de contrôle du résultat final.

Bob.

[Ry_Yo]

De ce que j'ai vu dans un fichier de scénario, il enregistre les handle et autres joyeusetés Windows pour reproduire le comportement homme dans le projet.
...

Tout à fait, et en mode strict, il se base aussi sur la barre de titre... Donc si vous avez une barre de titre gérer de manière dynamique (login / heure / etc...) ça ne fonctionne pas... il faut systématiquement décocher le mode strict.

@Grmmml : de ce point de vue, je suis d'accord, mais il permet "un peu" de soulager la partie test en cas d'évol ou modif pour éviter les régressions au point de vue fonctionnel. un début de TDD...

[Arnaud B.]

Bien sûr que si.
Tu peux contrôler les données par du code dans les scénarios de tests automatisés (c'est ce que je fais).

Vous confondez WDTest et les tests automatisés dans l'éditeur.

Pour ma part je le trouve complètement inutile (je n'ai pas regardé depuis la 10).
Faire un test ne se limite pas à cliquer sur des boutons pour éventuellement constater que les fenêtre s'ouvrent.

L'important c'est les données ! Et malheureusement, l'outil ne permet aucun contrôle sur celles-ci. Pas d'initialisation des données (BDD, fichiers, flux réseau, ...). Pas de contrôle du résultat final.

Bob.

[Grmmml]

Salut,

Bien sûr que si.
Tu peux contrôler les données par du code dans les scénarios de tests automatisés (c'est ce que je fais).

Vous confondez WDTest et les tests automatisés dans l'éditeur.

Effectivement, je ne pensais que WDTest. Merci pour l'info, je vais refaire un test du bouzin pour voire ce que je peux en tirer.

Bob.

[Arnaud B.]

Bon en revanche, ca reste effectivement un bouzin, mais on arrive à en faire qqchose.

La difficulté principale que j'ai rencontrée est que si on enregistre le comportement de l'utilisateur, ca génère un scénario par fenetre et ca devient vite la pagaille pour enchainer les scénarios.

J'ai pris le parti de faire manuellement le code qui va bien, et de mettre tout ce code dans une seule fenêtre, qui est le point de départ de mes tests (la fenêtre principale de l'application en fait).

Cdlt, Arnaud.

Salut,



Effectivement, je ne pensais que WDTest. Merci pour l'info, je vais refaire un test du bouzin pour voire ce que je peux en tirer.

Bob.

[Grmmml]

J'ai fais de nouveau essai avec les tests. Y'à possibilité de créer des tests unitaires et c'est déjà bien pour les classes et procédures locales/globales.
Ca reste malheureusement du pcsoft et c'est comme d'habitude fait a moitié.

On ne peut faire que des tests de réussite et pas de tests d'échecs.
En plus ca plante quand je veux retirer une "itération" de test sur une proc locale.
Mais y'a du progrès.

Par contre je persiste, y'a toujours pas de solution simple et intégré pour gérer le contenu des données (BDD) dans les tests (ou alors j'ai vraiment pas trouvé)

Pour l'IHM je trouve que encore juste du "push button" mais j'ai pas eu le courrage de re tester en profondeur

Bob.

J'ai pris le parti de faire manuellement le code qui va bien, et de mettre tout ce code dans une seule fenêtre, qui est le point de départ de mes tests (la fenêtre principale de l'application en fait).

Cdlt, Arnaud.

[Arnaud B.]

Ca reste malheureusement du pcsoft et c'est comme d'habitude fait a moitié.

Je suis assez d'accord...

On ne peut faire que des tests de réussite et pas de tests d'échecs.
En plus ca plante quand je veux retirer une "itération" de test sur une proc locale.
Mais y'a du progrès.

Par contre je persiste, y'a toujours pas de solution simple et intégré pour gérer le contenu des données (BDD) dans les tests (ou alors j'ai vraiment pas trouvé)

Bob.

Les itérations, je n'ai jamais réussi à les faire fonctionner, sauf avec des procédures qui renvoient un booléen. Mais c'est loin d'être le cas de toutes mes procédures !!

Mais par ailleurs, tu peux tout faire du moment que tu mets le code correspondant dans le scénario, puisque tu peux utiliser tous les ordres windev habituels (conditions, hlit, etc...). Donc y compris tester les modifs sur la BDD.

Au final, il faut tout faire soi même, le seul (mais important) avantage des tests automatisés Windev étant d'avoir les fonctions Pilotesouris() qui permet de simuler le comportement de l'utilisateur.

Cdlt, Arnaud.