Ubuntu-fr

Spalax

Automatisation de tests de régression

Bonjour,
   je recherche un programme qui fasse seul des tests de régression.

  En gros, le principe de base serait : supposons que je sois en train de programmer un super logiciel. Je dit au programme de tests que l'exécution de ma_commande doit se terminer correctement (code de sortie nul), et afficher résultat de la commande sur la sortie standard.
  Ensuite, dès que j'ai modifié mon programe, et que je veux vérifier qu'il fonctionne toujours, je lance le programme de tests de régression, qui vérifie que mon logiciel s'exécute toujours correctement, et me signale une erreur si ce n'est pas le cas.

  J'ai déjà  cherché un peu sur internet, et je n'ai trouvé que des programmes de tests pour application web (va savoir pourquoi), ou des programmes de tests unitaires (donc spécifiques à  un langage de programmation, et qui ne permettent pas de tester le programme complet).
  J'ai trouvé dejagnu, qui semble intéressant, mais d'une part il a l'air très compliqué à utiliser (dans le tutorial, ils disent de créer un nouvel utilisateur pour exécuter les tests), et d'autre part, il semble plutôt orienté vers les tests de programmes nécessitant des interactions avec l'utilisateur (voire des interactions dans une interface graphique). De plus, il ne semble pas permettre de modifier les tests de manière dynamique (par exemple, le logiciel a été modifié, et bien que les tests ne correspondent plus, ils sont valides. Il serait interressant que le programme puisse automatiquement exécuter les tests et prendre les résultats comme résultats témoin).
  Bon, je cherche aussi un peu à me rassurer, et à me dire que le logiciel que je suis en train de coder et sur lequel j'ai déjà passé pas mal d'heure n'est pas inutile.

  Connaissez-vous de tels logiciels ?

  Merci d'avance,
  Spalax

JBF

Re : Automatisation de tests de régression

Bonsoir,

Comment veux-tu que le logiciel de test puisse deviner ce qu'est censé faire le programme à tester ?
Je ne vois pas d'autre possibilité que d'écrire des scripts qui simulent le comportement de l'utilisateur. Mais ces scripts seront spécifiques au programme à tester et si ce programme change il faudra modifier et compléter les tests.

JBF

---

LibreOffice : https://fr.libreoffice.org/ (téléchargement, documentation, FAQ, assistance, contribuer, ...)
Aide pour LibreOffice par la communauté francophone : https://ask.libreoffice.org/fr/

Spalax

Re : Automatisation de tests de régression

Je me suis mal fait comprendre. Premièrement, quand je parlais de programmes n'ayant pas d'interactions avec l'utilisateur, je voulais bien entendu dire : une fois la commande lancée, rien n'est demandé à l'utilisateur.

Ensuite, quand je parlais de mettre à jour les tests, voila un petit exemple. Il est volontairement très simple ; il faut imaginer un programme plus compliqué, avec donc une sortie standard qui évolue au fur et à mesure du code.
Supposons que je fasse un programme par qui affiche simplement ses arguments, mis entre parenthèse.

splax@pc $ par arg1 arg2
(arg1)(arg2)

Je fais une première version de mon programme, qui ne traite que le premier argument.

splax@pc $ par arg1 arg2
(arg1)

Je fais toute une série de tests, que je vérifie de temps en temps, pendant que je modifie une autre partie du programme.

Finalement, je code la seconde partie de mon programme, et j'affiche donc le second argument. Le logiciel de validation de tests va donc considérer que mes tests échouent, puisqu'ils n'affichent plus la valeur attendue. Ce que je souhaite, c'est qu'après avoir vérifié « à la main » que mes tests sont corrects, je puisse dire au logiciel de test de mette à jour sa base de tests, c'est-à-dire d'effectuer les tests, et d'enregistrer le résultat comme témoin pour des tests ultérieurs.

La mise à jour automatique de tests est certes un détail, mais dans un gros projet, on peut facilement faire des centaines de tests (je l'ai déjà fait), et changer manuellement tous les tests pour dire que finalement, la sortie correcte est « Erreur : syntaxe invalide » plutôt que « Erreur Syntaxe invalide » est pour le moins barbant.

Mais cette mise à jour automatique n'est qu'une des fonctionnalités que je souhaitais, et qui ne semble pas être présente dans dejagnu.

Je comptais décrire chaque test comme une commande (ou liste de commandes) dont on peut tester la sortie standard, la sortie d'erreur, le code de sortie, et des fichiers ayant été modifiés par effet de bord (on peut aussi bien entendu dire que, par exemple, on veut ignorer la sortie d'erreur pour ce test).
Il y aurait également la possibilité de précéder chaque test de commandes à exécuter avant (pour par exemple générer une série de tests), et après (pour nettoyer l'environnement) le test.

dekans

Re : Automatisation de tests de régression

regarde fitnesse ou selenium,
je ne suis pas sûr mais je crois que ça peut t'intéresser

---

dekans@jabber.kubuntu-fr.org

Yannick_LM

Re : Automatisation de tests de régression

Sinon, tu peux regarder du côte de darts + cmake, y a des trucs assez bien foutus.

(C'est un peu lourd à mettre en place si tu es le seul à coder, cela dit. Il me semble que c'est ce qu'utilise le projet KDE, pour te donner une idée)

Dernière modification par Yannick_LM (Le 06/07/2008, à 12:35)

---

Trucs et astuces pour Vim
Ma web page  avec des trucs dessus ...

Spalax

Re : Automatisation de tests de régression

Selenuim est orienté web ; le projet sur lequel je veut l'utiliser n'est pas un site internet.

Pour le reste, ça a l'air intéressant. Merci, je regarde ce soir et je vous tiens au courant.

dekans

Re : Automatisation de tests de régression

tes retours m'intéressent

---

dekans@jabber.kubuntu-fr.org

Spalax

Re : Automatisation de tests de régression

Alors, je viens d'essayer fitnesse et cmake, voici mes impressions :
* fitnesse fait « trop » de choses. Il y a surement moyen de faire autrement, mais la méthode par défaut est de lancer un serveur internet, et les tests sont effectués lorsque l'on s'y connecte et que l'on clique sur le lien « tests », ce qui n'est absolument pas ce que je veux. De plus, il se présente comme un outil de tests, de collaboration, de communication entre développeurs pour de gros projets ; je voulais simplement un outil de test. Il n'est donc pas adapté à ce que je veux faire.

* cmake + darts a l'air très bien, et ce ne serai sans doute pas une perte de temps que d'apprendre à s'en servir. Néanmoins, j'ai des reproches à faire.
Premièrement, s'il permet de faire énormément de choses, il semble très compliqué à comprendre. Ai-je l'envie et le courage d'apprendre à l'utiliser ?
Ensuite, la définition d'un test est à mon avis trop simpliste : il semble qu'un test soit réussi si le code de retour de la commande est 0, et échoue sinon. Mais il est possible que la philosophie du programme soit différente de ce que j'imaginais : un test serait un script qui exécute une commande, compare les résultats, et renvoie le bon code de sortie. La commande donnée à cmake comme test pour effectuer le test serait alors simplement le nom du script. Soit j'ai mal compris, soit ce doit tout de même être une bonne idée, puisque cmake semble être assez utilisé.
Enfin, vous allez dire que je radote, mais je trouve utile ma fonction de mise à jour des tests. Il est possible que mon besoin ou envie de cette fonction soit due à une mauvaise organisation de mon logiciel ou de mes tests.

Au final, je crois que je vais continuer de coder mon petit module de tests. Je le trouve plus simple. Ceci s'explique notamment par deux raisons.
Premièrement, cette idée est biaisée par le fait que c'est moi qui ai pensé le programme de tests que je compte réaliser
Deuxièmement, le but mon logiciel est aussi plus restreint que cmake, qui prévoit aussi par exemple l'exécution de tests à intervalle régulier (tous les jours, soirs...) et la publication sur un serveur. Le programme auquel je pense est plus destinée à un projet de plus petite envergure, avec moins de développeurs...

Merci pour votre aide,
Spalax

Yannick_LM

Re : Automatisation de tests de régression

Au final, je crois que je vais continuer de coder mon petit module de tests.

On est jamais si bien servi que par soi-même

---

Trucs et astuces pour Vim
Ma web page  avec des trucs dessus ...

Spalax

Re : Automatisation de tests de régression

Tout à fait Et puis comme ça, je m'entraine un peu au Python (c'est la première fois que j'utilise ce langage), avant de commencer une "commande" pour mon Grand-Père.

Dernière modification par Spalax (Le 07/07/2008, à 13:21)

Martopioche

Re : Automatisation de tests de régression

Bonjour,

Ouch... Je lis ici des trucs qui me font un peu peur... Explications :

Spalax, tu souhaite un outil de "test de non régression" qui s'adapte à "l'évolution de ton application". Répondons simplement : cet outil n'existe pas. La raison est que tu prend le problème à l'envers. En effet, comment veut tu que l'outil fasse la différence entre une évolution et une régression ? Ensuite, comment veut tu qu'un outil estime la non régression en en scrutant que la globalité de ton application ?

La réponse à ton problème réside dans les tests unitaires. Non, les tests unitaires ne sont pas spécifiques à un langage, mais oui, il existe des outils spécifiques à certains langages (jUnit pour java par exemple).

Le principe d'un test unitaire est de tester une fonctionnalité de ton application. Et surtout un test unitaire une fois définit, décrit une intention, il n'a donc pas à être modifié à moins que ta conception change. Alors tu a plutôt un problème d'organisation. Enfin, évidemment, si la fonctionnalité doit évoluer, le test aussi.

Dans l'approche dite du Test Driven Development, développement dirigé par les tests, l'objectif est d'écrire dans un premier temps ce test unitaire qui déclarera les intentions de ta fonction. Ce test sera en échec car ta fonctionnalité n'est pas codée. Tu écrit alors le code qui permet de passer ce test. A cette étape, tu a en effet ta fonctionnalité, mais de manière "sale". Tu peu ensuite chercher à optimiser ta fonction, ou tu te rend compte que cette fonction a des fonctionnalités partagée par d'autres qu'il peut être utile de refactorer. Ce (ces) test(s), auxquels tu ne touchera plus, seront les garants de la non régression lors de tes modifications.

Par contre, l'exemple que tu nous a cité démontre une mauvaise démarche. En effet, soit tu dispose d'un test qui confirme la sortie et il ne passera que quand tu aura tout écrit, soit la complexité de génération de chacune des parties est telle que tu a forcement des appels à d'autres fonction pour lesquelles tu doit écrire des tests. Ou alors tu a une fonction unique tellement complexe qu'elle risque d'être impossible à maintenir.

Enfin, tu utilise Python donc. Classe, Python embarque de quoi se tester lui même. Mais je suis un peu rouillé pour te donner des pistes

Spalax

Re : Automatisation de tests de régression

Bonjour,

Spalax, tu souhaite un outil de "test de non régression" qui s'adapte à "l'évolution de ton application". Répondons simplement : cet outil n'existe pas. La raison est que tu prend le problème à l'envers. En effet, comment veut tu que l'outil fasse la différence entre une évolution et une régression ?

Comme je l'ai déjà dit, c'est moi qui dit au logiciel de tests quand mon logiciel évolue.
Concrètement, si je teste la levée d'erreur en cas d'anomalies dans un fichier, et que je décide que je vais finalement afficher Ligne 3 - Erreur : plutôt que Erreur (3eme ligne) :, bien sûr que je ne m'attends pas à ce que le programme devine tout seul que c'est une évolution et non une régression. Ce que je veux pouvoir faire, c'est dire au logiciel « le résultat des tests suivants a changé, et tu prends les nouvelles valeurs comme valeur de référence pour les tests ultérieurs ».
Encore une fois, pour de gros projets, on peut facilement être amené à faire un grand nombre de tests, et je trouve qu'une telle fonction serait pratique.

Le principe d'un test unitaire est de tester une fonctionnalité de ton application. Et surtout un test unitaire une fois définit, décrit une intention, il n'a donc pas à être modifié à moins que ta conception change. Alors tu a plutôt un problème d'organisation. Enfin, évidemment, si la fonctionnalité doit évoluer, le test aussi.

Je connais le principe des tests unitaire, mais il y a bien un moment où l'on veut s'assurer que, même si les différents modules d'un programme font ce qu'on attend d'eux, ils se comportent toujours correctement lorsqu'on les assemble.
Il est possible que chaque fonction soit correcte, mais que l'on ait fait une erreur dans l'assemblage des fonctions entre elles.
Et à moins d'utiliser la méthode B ou une méthode similaire, je ne vois pas comment on peut garantir, en se contentant de regarder le code, ou de tester chaque fonction ou module individuellement, que l'agencement des fonctions soit correct.

Par contre, l'exemple que tu nous a cité démontre une mauvaise démarche. En effet, soit tu dispose d'un test qui confirme la sortie et il ne passera que quand tu aura tout écrit, soit la complexité de génération de chacune des parties est telle que tu a forcement des appels à d'autres fonction pour lesquelles tu doit écrire des tests. Ou alors tu a une fonction unique tellement complexe qu'elle risque d'être impossible à maintenir.

Je ne vois pas en quoi cet exemple est nécessairement la preuve d'une mauvaise méthode. Supposons que mon programme se fasse en plusieurs phases, qui affichent chacunes un compte rendu sur la sortie standard. Je veux tester (en plus des tests unitaires), l'enchaînement de ces phases sur un exemple concret, en conditions quasi-réelles.
Je ne vois pas pourquoi avoir un test qui vérifie la sortie standard, et qui donc en vérifie de plus en plus au fur et à mesure que je code les différentes parties, est une mauvaise chose.
Oui, les tests unitaires sont utiles. Mais je pense que ce que je propose est complémentaire, pour tester si les fonctions sont correctement agencées les unes avec les autres.

Je suis en train de construire un mur. Les tests unitaires vérifient si les briques sont sans défaut, mais j'aimerais en plus pouvoir vérifier que mon mur, dans sa globalité, est droit. Même si le mur n'est pas terminé, et évolue, je peux toujours prendre un fil à plomb et vérifier que mon mur est droit. Le programme que je cherchais/décrivais est ce fil à plomb.

Enfin, tu utilise Python donc. Classe, Python embarque de quoi se tester lui même. Mais je suis un peu rouillé pour te donner des pistes

unittest semble faire ça pas mal.

  Spalax

Spalax

Re : Automatisation de tests de régression

@Martopioche Est-ce que ça te choque moins si je parle de tests d'intégration plutôt que de tests de régression (bien que mes tests, finalement, vérifient également la non-régression) ?
Même si le projet n'est pas terminé, ça ne me paraît pas incohérent de faire des tests d'intégration sur un programme incomplet : attendre que ce dernier soit terminé, même si l'on a fait des tests unitaires, se rapproche de la programmation Big Bang, non ?

Martopioche

Re : Automatisation de tests de régression

@Martopioche Est-ce que ça te choque moins si je parle de tests d'intégration plutôt que de tests de régression (bien que mes tests, finalement, vérifient également la non-régression) ?

Lol

Je serai intervenu avant ce message, à la lecture du précédent post je t'aurai justement cité ces fameux tests d'intégration. La différence entre un test unitaire et un test d'intégration tient finalement des relations entre ce qui est testé et ce qui est en relation avec ce qui est testé. Dans un test unitaire, tu va éviter au maximum les interactions avec d'autres implémentations. L'objectif d'un test est de démontrer que ta fonction remplit son rôle. En effet, par la suite, il doit signaler la non régression. Bon, j'en reviens à ton exemple.

Tu dis

Supposons que mon programme se fasse en plusieurs phases, qui affichent chacunes un compte rendu sur la sortie standard. Je veux tester (en plus des tests unitaires), l'enchaînement de ces phases sur un exemple concret, en conditions quasi-réelles

Ok. Mais que doit tu tester ? Il y a plusieurs phases dans ton programme (et là désolé je bascule en réflexion "objet" ) et c'est normal : en général une pour récupérer l'information, une pour la traiter, une pour l'afficher (c'est bien une simplification de l'appli pour pépé non ? ). Ok, alors que doit tu tester ? Pour moi, il y a :
- Tester que tu accède à un fichier contenant tes données (présence du fichier), puis tester l'accès aux données (parsing). Evidemment, tester la gestion des erreurs. Tes tests, évidemment tu les fait sur des fichiers "type" au contenu contrôlé et maitrisé.
- Tester la fonctionnalité de détermination de la bonne date. Evidemment, pour un test unitaire, ça va être tendu car d'après mes sources, la date change tous les jours . Ton test unitaire va tester la simple fonctionnalité, ton test d'intégration va faire pareil mais avec la fonctionnalité d'accès aux fichiers.
- Tester que l'affichage fonctionne bien. Seulement, pour tester la fonctionnalité d'affichage, on se fiche qu'il s'agisse de dates d'anniversaire ou des proverbes.

La démarche quand on décide de faire attention à la qualité de ce que l'on produit (donc de mettre en place des tests) n'est pas d'écrire quelque chose pour vérifier que l'échafaudage est bien là puis qu'il s'est bien déplacé. L'idéal est de se dire "bon, là j'implante telle fonctionnalité, que doit elle faire ? Parcourir le fichier calendrier ? Ok, que doit elle faire ? Ouvrir un fichier. Ok, écrivons un test pour un fichier qui existe et celui si il n'existe pas/n'est pas du bon format... Ok, un autre pour voir si on retrouve l'information, et si on la retrouve pas. Etc, etc. Ok, j'ai mes tests. Bon, maintenant, quel est mon code. Ok, c'est bon, ca passe les tests passent. Ok, j'ai bien réfléchit à mes tests, et tout est ok. Mais hier, j'ai codé la comparaison de dates. Bon, ben maintenant écrivons un test qui passe la date trouvée avec ma méthode d'aujourd'hui. Puis un autre ou ça n'ouvre pas le fichier/trouve pas l'info, etc, etc. Arf, j'ai oublié de gérer un cas hier..." là tu va compléter ce que tu a oublié, et en effet le jeu va être que les tests existants qui sont au vert restent au vert.

Voila, je ne sais pas si j'ai été plus claire dans mon opinion, et je suis désolé si il y a trop de détails mais je souhaite que si d'autres personnes plus néophytes lisent ce poste, elles puissent comprendre la démarche.

Bon, sur ce dodo