Bien décidé à fournir du code propre et testé, je cherche quelque
chose me permettant de faire des tests unitaires et/ou de non
regression pour du code emacs lisp.
J'aimerais avoir vos conseils à ce sujet étant donné que je n'ai
jamais produit de tels tests auparavant (et ce quelque fut le
langage utilisé).
Comment s'y prendre ? Existe-t-il des outils dédiés pour le cas
qui nous concerne: Emacs Lisp ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
drkm
Xavier Maillard writes:
Bien décidé à fournir du code propre et testé, je cherche quelque chose me permettant de faire des tests unitaires et/ou de non regression pour du code emacs lisp.
Je sais qu'il y a une page et un module sur EmacsWiki, mais je n'y ai encore jamais jeté un oeil :
En gros, l'idée semble d'insérer les tests directement dans le code. Je ne trouve pas personnellement l'idée excesivement intéressante. A priori, je dirais que cela dois surcharger les sources. Sans doute les dévots d'XP trouveront-ils cela plus intéressant que moi.
Sinon, si je me souviens bien, CC Mode dispose d'un tel outil sur la version CVS. Il doit y avoir un fichier 'test/000test.el' ou quelque chose comme ça (commençant par '000', tu le trouveras facilement).
Je n'ai jamais eu vent d'une implémentation JUnit-like pour Emacs avec EIEIO, mais il ne devrait pas être très compliqué de s'inspirer des implémentations CL existantes. Pour des idées :
Si tu trouves des choses intéressantes, tiens-nous au courant ...
--drkm
Xavier Maillard writes:
Bien décidé à fournir du code propre et testé, je cherche quelque
chose me permettant de faire des tests unitaires et/ou de non
regression pour du code emacs lisp.
Je sais qu'il y a une page et un module sur EmacsWiki, mais je
n'y ai encore jamais jeté un oeil :
En gros, l'idée semble d'insérer les tests directement dans le
code. Je ne trouve pas personnellement l'idée excesivement
intéressante. A priori, je dirais que cela dois surcharger les
sources. Sans doute les dévots d'XP trouveront-ils cela plus
intéressant que moi.
Sinon, si je me souviens bien, CC Mode dispose d'un tel outil
sur la version CVS. Il doit y avoir un fichier 'test/000test.el'
ou quelque chose comme ça (commençant par '000', tu le trouveras
facilement).
Je n'ai jamais eu vent d'une implémentation JUnit-like pour
Emacs avec EIEIO, mais il ne devrait pas être très compliqué de
s'inspirer des implémentations CL existantes. Pour des idées :
Bien décidé à fournir du code propre et testé, je cherche quelque chose me permettant de faire des tests unitaires et/ou de non regression pour du code emacs lisp.
Je sais qu'il y a une page et un module sur EmacsWiki, mais je n'y ai encore jamais jeté un oeil :
En gros, l'idée semble d'insérer les tests directement dans le code. Je ne trouve pas personnellement l'idée excesivement intéressante. A priori, je dirais que cela dois surcharger les sources. Sans doute les dévots d'XP trouveront-ils cela plus intéressant que moi.
Sinon, si je me souviens bien, CC Mode dispose d'un tel outil sur la version CVS. Il doit y avoir un fichier 'test/000test.el' ou quelque chose comme ça (commençant par '000', tu le trouveras facilement).
Je n'ai jamais eu vent d'une implémentation JUnit-like pour Emacs avec EIEIO, mais il ne devrait pas être très compliqué de s'inspirer des implémentations CL existantes. Pour des idées :
Si tu trouves des choses intéressantes, tiens-nous au courant ...
--drkm
Matthieu Moy
Xavier Maillard writes:
Bonsoir,
Bien décidé à fournir du code propre et testé, je cherche quelque chose me permettant de faire des tests unitaires et/ou de non regression pour du code emacs lisp.
Y'a des choses comme ça dans BBDB. On a un petit environnement de test dans Xtla dont tu peux t'inspirer (mais en fait, on l'utilise quasiment pas).
-- Matthieu
Xavier Maillard <zedek@gnu-rox.org> writes:
Bonsoir,
Bien décidé à fournir du code propre et testé, je cherche quelque
chose me permettant de faire des tests unitaires et/ou de non
regression pour du code emacs lisp.
Y'a des choses comme ça dans BBDB. On a un petit environnement de test
dans Xtla dont tu peux t'inspirer (mais en fait, on l'utilise
quasiment pas).
Bien décidé à fournir du code propre et testé, je cherche quelque chose me permettant de faire des tests unitaires et/ou de non regression pour du code emacs lisp.
Y'a des choses comme ça dans BBDB. On a un petit environnement de test dans Xtla dont tu peux t'inspirer (mais en fait, on l'utilise quasiment pas).
-- Matthieu
drkm
Matthieu Moy writes:
Y'a des choses comme ça dans BBDB.
Qui ne se trouve que sur le CVS, pas dans l'archive.
On a un petit environnement de test dans Xtla dont tu peux t'inspirer (mais en fait, on l'utilise quasiment pas).
Je viens de jeter un oeil (très) rapide aux deux. Et un autre à 'cc-mode/test/000tests.el'. Il me semble que les points communs sont :
1/ le moyen d'initialiser un test. Soit avant chaque test, soit directement dans le code de chargement du module de test ;
2/ quelques routines simples de logging ;
3/ quelques routines simples de conduite de test ;
4/ quelques outils d'aide à l'écriture des fonctions de test, comme comparer deux buffers, vérifier la fontification, etc. Mais là, on est déjà dans le domaine d'application.
ÀMHA, il pourrait être intéressant d'écrire quelques fonctions générales de conduite de test et de logging, destinées à être réutilisées.
Mais pour le reste, ça devient vite dépendant de ce que l'on teste, et vouloir généraliser à ce niveau n'est pas très intéressant, ÀMHA (il serait souvent plus rapide d'écrire quelques fonctions dédiées au test du projet en question).
En fait, ce que je trouverais intéressant, c'est une interface commune. Comment démarrer un test (une batterie de tests), et comment exploiter le résultat. Il faudrait donc définir comment enregistrer les tests écrits, et comment ils communiquent leur résultat.
De là, on peut définir un mode à la Compile Log ou Compile Errors, qui affiche les résultats fontifiés, permet d'utiliser 'next-error' et fournit un moyen de sauter directement au bon endroit dans le fichier de test (voire même dans le code testé, si l'on peut fournir cette info à l'inscription du test).
Éventuellement fournir le moyen de générer un rapport de bug. Il suffit de fournir une adresse email pour l'ensemble des tests, une description de l'erreur par test, et un backtrace. Bref, toutes choses normalement disponibles aisément lorsque l'on programme un test.
Bref, quelques idées en vrac.
--drkm
Matthieu Moy writes:
Y'a des choses comme ça dans BBDB.
Qui ne se trouve que sur le CVS, pas dans l'archive.
On a un petit environnement de test dans Xtla dont tu peux
t'inspirer (mais en fait, on l'utilise quasiment pas).
Je viens de jeter un oeil (très) rapide aux deux. Et un autre
à 'cc-mode/test/000tests.el'. Il me semble que les points
communs sont :
1/ le moyen d'initialiser un test. Soit avant chaque test,
soit directement dans le code de chargement du module de
test ;
2/ quelques routines simples de logging ;
3/ quelques routines simples de conduite de test ;
4/ quelques outils d'aide à l'écriture des fonctions de test,
comme comparer deux buffers, vérifier la fontification,
etc. Mais là, on est déjà dans le domaine d'application.
ÀMHA, il pourrait être intéressant d'écrire quelques fonctions
générales de conduite de test et de logging, destinées à être
réutilisées.
Mais pour le reste, ça devient vite dépendant de ce que l'on
teste, et vouloir généraliser à ce niveau n'est pas très
intéressant, ÀMHA (il serait souvent plus rapide d'écrire
quelques fonctions dédiées au test du projet en question).
En fait, ce que je trouverais intéressant, c'est une interface
commune. Comment démarrer un test (une batterie de tests), et
comment exploiter le résultat. Il faudrait donc définir comment
enregistrer les tests écrits, et comment ils communiquent leur
résultat.
De là, on peut définir un mode à la Compile Log ou Compile
Errors, qui affiche les résultats fontifiés, permet d'utiliser
'next-error' et fournit un moyen de sauter directement au bon
endroit dans le fichier de test (voire même dans le code testé,
si l'on peut fournir cette info à l'inscription du test).
Éventuellement fournir le moyen de générer un rapport de bug.
Il suffit de fournir une adresse email pour l'ensemble des tests,
une description de l'erreur par test, et un backtrace. Bref,
toutes choses normalement disponibles aisément lorsque l'on
programme un test.
Qui ne se trouve que sur le CVS, pas dans l'archive.
On a un petit environnement de test dans Xtla dont tu peux t'inspirer (mais en fait, on l'utilise quasiment pas).
Je viens de jeter un oeil (très) rapide aux deux. Et un autre à 'cc-mode/test/000tests.el'. Il me semble que les points communs sont :
1/ le moyen d'initialiser un test. Soit avant chaque test, soit directement dans le code de chargement du module de test ;
2/ quelques routines simples de logging ;
3/ quelques routines simples de conduite de test ;
4/ quelques outils d'aide à l'écriture des fonctions de test, comme comparer deux buffers, vérifier la fontification, etc. Mais là, on est déjà dans le domaine d'application.
ÀMHA, il pourrait être intéressant d'écrire quelques fonctions générales de conduite de test et de logging, destinées à être réutilisées.
Mais pour le reste, ça devient vite dépendant de ce que l'on teste, et vouloir généraliser à ce niveau n'est pas très intéressant, ÀMHA (il serait souvent plus rapide d'écrire quelques fonctions dédiées au test du projet en question).
En fait, ce que je trouverais intéressant, c'est une interface commune. Comment démarrer un test (une batterie de tests), et comment exploiter le résultat. Il faudrait donc définir comment enregistrer les tests écrits, et comment ils communiquent leur résultat.
De là, on peut définir un mode à la Compile Log ou Compile Errors, qui affiche les résultats fontifiés, permet d'utiliser 'next-error' et fournit un moyen de sauter directement au bon endroit dans le fichier de test (voire même dans le code testé, si l'on peut fournir cette info à l'inscription du test).
Éventuellement fournir le moyen de générer un rapport de bug. Il suffit de fournir une adresse email pour l'ensemble des tests, une description de l'erreur par test, et un backtrace. Bref, toutes choses normalement disponibles aisément lorsque l'on programme un test.
