Discussion :

[tunizar]

Bonjour,
Une question assez rare, comment est-il possible de connaitre le taux de couverture de code dans les tests unitaires WinDev. Dans d'autres environnement il y a des plugins et des Framework spéciales.
J'ai vu dans l'exemple WD Exemple de test unitaire, il y a le test unitaire automatique TEST_Procedures_globales\Test de surface du code, mais je ne suis pas convaincu par ça !
A votre avis comment faire ?

[R&B]

Les tests WinDev reproduisent des scénarios de comportement (clic + datas) que l'on établi nous même.
Ainsi donc il n'y a rien de vraiment structuré pour ce point lors du déroulement d'un test qui permette de répondre à ta question.
En effet, je n'ai rien vu qui mesure si on est passé par là ou pas.
Cela implique que le sujet soit si peu pratiqué car peu nombreux sont les utilisateurs de WinDev (10x+vite) qui prennent le temps de prévoir les tests au même moment qu'ils décident de programmer.
Ce manque dans l'EDI illustre la situation.

La question mérite une grande attention.
Illustration de ta demande : entre deux version, comment savoir si le test prends en compte une nouvelle fonctionnalité / passe dans un nouveau comportement ?

[Ry_Yo]

A une époque, j'avais commencé à vouloir faire un composant qui soit capable justement de sortir un jeu de test, déroulé des scénarios qui n'était pas lié à l'IHM, savoir quelles fonctions n'était pas appelé à la fin de la batterie de test, etc.. Mais je me suis vite aperçu, qu'il me manquait une info majeur pour réaliser cela, c'est l'énumération complète d'un projet.

La fonction EnumèreElement n'est pas capable de lister les procédures (globale ou locale) et la liste des états d'un projet...
bref j'ai envoyé la suggestion à PCSOFT il y a quelques années, hélas... ils n'ont jamais pris la peine de compléter leur fonction EnumèreElement()

Donc n'hésitez à envoyer cette suggestion aussi, comme ça on pourra facilement créer un composant allant dans ce sens, et ça sera juste un process à rajouter lors de la création d'un nouveau projet qui par la suite gérera en automatique les différents test ou reccouvrement de code

[tunizar]

Les tests WinDev reproduisent des scénarios de comportement (clic + datas) que l'on établi nous même.
Ainsi donc il n'y a rien de vraiment structuré pour ce point lors du déroulement d'un test qui permette de répondre à ta question.
En effet, je n'ai rien vu qui mesure si on est passé par là ou pas.
Cela implique que le sujet soit si peu pratiqué car peu nombreux sont les utilisateurs de WinDev (10x+vite) qui prennent le temps de prévoir les tests au même moment qu'ils décident de programmer.
Ce manque dans l'EDI illustre la situation.

La question mérite une grande attention.
Illustration de ta demande : entre deux version, comment savoir si le test prends en compte une nouvelle fonctionnalité / passe dans un nouveau comportement ?

Merci pour ta réponse,
J'ai pu avancé dans les tests unitaires automatiques avec l'écriture du code dans le scénario de test

et ça marche parfaitement, j'ai pu aussi fabriquer un reporting du résultat de ces tests que je consulte < en dehors de l'environnement WinDev > en plus de celui de la fonction TestWriteResultet
Pièce jointe 158023

WinDev permet de connaitre les éléments qui n'ont pas de tests unitaires et même donner des statistiques
Pièce jointe 158024

Il me manque un truc qui me dit est ce que j'ai tout testé dans l'élément ou il en manque encore et quel pourcentage
Pièce jointe 158026

[tunizar]

A une époque, j'avais commencé à vouloir faire un composant qui soit capable justement de sortir un jeu de test, déroulé des scénarios qui n'était pas lié à l'IHM, savoir quelles fonctions n'était pas appelé à la fin de la batterie de test, etc.. Mais je me suis vite aperçu, qu'il me manquait une info majeur pour réaliser cela, c'est l'énumération complète d'un projet.

La fonction EnumèreElement n'est pas capable de lister les procédures (globale ou locale) et la liste des états d'un projet...
bref j'ai envoyé la suggestion à PCSOFT il y a quelques années, hélas... ils n'ont jamais pris la peine de compléter leur fonction EnumèreElement()

Donc n'hésitez à envoyer cette suggestion aussi, comme ça on pourra facilement créer un composant allant dans ce sens, et ça sera juste un process à rajouter lors de la création d'un nouveau projet qui par la suite gérera en automatique les différents test ou reccouvrement de code

Tu veux dire :
1/ Collecter les informations depuis toutes les pile d'appel
2/ Énumérer tout les éléments du projet
3/ Comparer la première collecte au contenu de l'énumération
4/ sortir les stat issu de cette comparaison

??
c'est ça ?

[Ry_Yo]

Le but était de faire un composant capable de faire des test unitaire, fonctionnel et d'autre fonction "qualité"

Un peu comme l'ancien leader du marché Mercury, qui a été racheté par HP maintenant :
http://www8.hp.com/us/en/software-so...ng-automation/

Donc à partir d'un programme maître, on "pourrait" interagir sur un programme incluant ce composant....

Car le test unitaire que propose PCSOFT est "pauvre" dans le sens où je change d'environnement, de résolution d'écran, le test n'est plus faisable. Et si c'est une application MDI, avec des fenêtre filles non-maximisée, alors l'automate de PC-SOFT sera dans les choux Bref, on récupère toutes les contraintes liées à l'IHM.

Alors l'avantage que je vois en tant que développeur, c'est que je peux facilement créer un lien entre le programme en cours de dev. et le programme "maître" de qualité....

Un exemple classique sans changer la résolution, j'inverse le bouton "enregistrer" et "fermer" le test unitaire devra être ré-écrit... par contre si à la base, je peux énumérer tous les éléments d'un projet et leur donner un "sens", alors lors de l'écriture de mon test, l'inversion de bouton n'aura aucun impact.

Bref, on est bien au delà du test unitaire (celui fait par le dev.), on est plus accès test fonctionnel avec analyse d'impact.

[tunizar]

...
Un exemple classique sans changer la résolution, j'inverse le bouton "enregistrer" et "fermer" le test unitaire devra être ré-écrit... par contre si à la base, je peux énumérer tous les éléments d'un projet et leur donner un "sens", alors lors de l'écriture de mon test, l'inversion de bouton n'aura aucun impact....

.

Non !
EmulateMouse(LaFenêtre.Btn_Annuler,dmLeftClickLaFenêtre..Btn_Annuler..Width/2,LaFenêtre..Btn_Annuler..Height/2)

Quant à la MDI , il faut que tu te rappel que le test unitaire doit être isolé !! Donc la fenêtre fille doit être lancée toute seule dans son T.U

t'as pas répondu à ma question précédente Oui ou non ? ou il y a des rectification dans la réflexion que j'ai fais ?

[Ry_Yo]

...EmulateMouse(LaFenêtre.Btn_Annuler,dmLeftClickLaFenêtre..Btn_Annuler..Width/2,LaFenêtre..Btn_Annuler..Height/2)...

Autant pour moi Windev remonte dans mon estime de ce point de vue ^^
Je n'avais pas re-tester les test automatique de Windev depuis (WD10) !

...Tu veux dire :
1/ Collecter les informations depuis toutes les pile d'appel
2/ Énumérer tout les éléments du projet
3/ Comparer la première collecte au contenu de l'énumération
4/ sortir les stat issu de cette comparaison

??
c'est ça ?

Oui et non

Par rapport à ta demande initiale, oui, pour moi tu couvres le périmètre des T.U.
Concernant le % de couverture, c'est une notion subjective. Elle est fortement lié au contexte. Pour un programme de pilotage d'avion ou de gestion d'une centrale nucléaire, la couverture va être très proche de 100%, mais pour un programme pour M. letruc qui a demandé un petit programme de gestion de contact, le % de couverture sera de 80-90% selon l'investissement que le client/dév. veut y mettre.

Mais dans le cycle de vie de l'application, cela ne suffira pas. un "T.U" peux passer au vert, mais fonctionnellement ça peut être un non-sens voire une erreur grave.
Donc accepter une évolution est vérifié ses "T.U" ne sera pas un gage de qualité. Il faut donc aussi prévoir les tests fonctionnelles (est-ce que Windev à évoluer de ce côté aussi ? pouvoir faire des boucles avec des valeurs choisi ou aléatoire)
Les tests fonctionnels couvrent également la robustesse de l'application (montée en charge par exemple), car le T.U peut être OK, mais dans un contexte multi-accès ou autre... cela peut- s'avérer catastrophique.

Ensuite tu as les tests structurels à implémenter, c'est à dire tous les cas d'erreur, et plantage de l'application, est-ce trop verbeux, pas assez ? est-ce que le plantage corrompt les données (ex. de transaction non-gérer dans la suppression d'enreg ou autre...). Est-ce que l'erreur va générer d'autres erreurs critique ou mineur si l'application continu...

Bref, si on se lance dans cette "usine" ^^ on se rend bien compte que c'est un métier à part entière et pas seulement le travail du dév. lorsqu'il code.... Certes c'est toujours plus facile quand c'est le dév. qui fait les tests, puisqu'il a théoriquement la connaissance du code et des spécifications.

Ai-je répondu à ta question ce coup-ci ?

[R&B]

Voila pourquoi (en partie) je part sur une architecture en composants internes où chaque composant est dans son propre projet...
La partie composant est partagée via le GDS, la partir projet... héberge les tests et un modèle d'utilisation du composant.
Ainsi, avant tout renvoi dans le GDS et donc partage aux projets utilisant le composant, le test doit être lancé.

note : le TU est alors indépendant du projet qui utilise le composant et on peut conserver une IHM adaptée

Si les tests unitaires prévus échoue, on ne met pas en péril le projet qui utilise le composant.
Ensuite, dans le projet, les tests sont des tests d'intégration/fonctionnels et plus les T.U. des composants.