Discussion :

[rosty38]

Bonjour,
j'ai un script qui comporte un enssemble de fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
def func1(parm1, parm2):
        traitement
        return resultat
 
 
def func2(parm5, parm6, param7, param8):
        traitement
        return resultat

je souhaite tester ses fonction avec differents paramettres
pour le moment j'utilise se script :
func1.py

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
tests_func1 = [[func1, ()]] # Default args
for m_sec in repeat_alarm:
    tests_func1 = .append([func1__, (param1, param2  )])
 
def func1_test():
 
    return tests_func1

func2_test.py

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
tests_func2 = [[func2, ()]] # Default args
for m_sec in repeat_alarm:
    tests_func2 = .append([func2__, (param5, param6, param7, param8  )])
 
def func2_test():
 
   return  tests_func2

je voulais savoir si il y a pas moyen de definir ses testes(ses appels) dans un fichier .txt
du coup j'aurais un seul fichier sous cette forme

[func2__, ('a', 56, [], 'b' )]
[func2__, ('a1', 561, [1], 'b1' )]
[func2__, ('a2', 562, [1,2], 'b2' )]
[func1__, (99, 'b' )]
[func1__, (154,'rfe' )]
..........

puis les recuperer plus tard
j'ai regarder du cote de PICKLE mais ce n'est pas simple a ecrire dans un fichier texte.
avez vous une idée???

[wiztricks]

Salut,

je voulais savoir si il y a pas moyen de definir ses testes(ses appels) dans un fichier .txt du coup j'aurais un seul fichier sous cette forme

Un script Python est déjà un fichier texte avec une syntaxe régulière...
Pourquoi ne pas avoir un script: test_func2.py dans lequel seraient faits des tests unitaires associés à func2 avec la variabilité désirée de ses paramètres d'appels, le tests des résultats obtenus, incluant la documentation des tests faits/non faits...

En écrivant une liste style:

• [func2__, ('a', 56, [], 'b' )]
• [func2__, ('a1', 561, [1], 'b1' )]
• [func2__, ('a2', 562, [1,2], 'b2' )]

vous n'avez pas encore intégré de tests sur le résultat 'attendu'...

Pourquoi faire un "texte" autre qu'il va falloir transformer avant de pouvoir l'interpréter en Python. Comme Python n'est pas "compilé", modifier un tests peut se faire en modifiant le script de tests correspondant...
Ce qui n'empêche pas de factoriser certaines choses via des listes ou des dictionnaires ou des bases de données.

Plus généralement, je ne comprends pas l'intérêt de faire une usine à gaz pour réaliser des tests alors que des frameworks existent (testunit, doctest, nose,...). Ils sont documentés et similaires à ceux qu'on trouve pour d'autres langages.

Imaginez les difficultés des personnes qui devront dans 6 ou 9 mois ajouter des tests a votre suite de tests? Les faire tourner? Comprendre pourquoi ils ne fonctionnent pas en se posant des tas de questions sur comment vous avez codé cela?
- W

[rosty38]

merci pour votre reponse
en fait l'idée du fichier texte est liée au fait que des utilisateurs non informaticien doivent pouvoir ajouter des batterie de testes ( qui correspond a un dossier qui contient un fichier ou ils peuvent rajouter une liste de teste a volonté)
car pour le moment le fichier teste contient une liste écrite en python (list_test.append(['func1', param1...]))
je me suis dis que c'est plus facile pour eux d'écrire une suite de ligne qui se ressemble

[rambc]

Bonsoir.

je souhaite tester ses fonction avec differents paramettres

Ce message donne des façons de concevoir des tests.

[rosty38]

en fait le but n'est pas de faire des testes unitaire mais d'exécuter des fonctions , et on doit être capable de rajouter des centaines ou millier de testes a la main pour chaque fonction , et je vois mal un non informaticien écrire du code python
exemple , teste de la fonction COS

-- zeros
<testid> <function> <input_value> -> <output_value> <flags>

acos0000 acos 0.0 0.0 -> 1.5707963267948966 -0.0
acos0001 acos 0.0 -0.0 -> 1.5707963267948966 0.0
acos0002 acos -0.0 0.0 -> 1.5707963267948966 -0.0
acos0003 acos -0.0 -0.0 -> 1.5707963267948966 0.0

-- branch points: +/-1
acos0010 acos 1.0 0.0 -> 0.0 -0.0
acos0011 acos 1.0 -0.0 -> 0.0 0.0
acos0012 acos -1.0 0.0 -> 3.1415926535897931 -0.0
acos0013 acos -1.0 -0.0 -> 3.1415926535897931 0.0

-- values along both sides of real axis
acos0020 acos -9.8813129168249309e-324 0.0 -> 1.5707963267948966 -0.0
acos0021 acos -9.8813129168249309e-324 -0.0 -> 1.5707963267948966 0.0
acos0022 acos -1e-305 0.0 -> 1.5707963267948966 -0.0
acos0023 acos -1e-305 -0.0 -> 1.5707963267948966 0.0
acos0024 acos -1e-150 0.0 -> 1.5707963267948966 -0.0
acos0025 acos -1e-150 -0.0 -> 1.5707963267948966 0.0
acos0026 acos -9.9999999999999998e-17 0.0 -> 1.5707963267948968 -0.0
acos0027 acos -9.9999999999999998e-17 -0.0 -> 1.5707963267948968 0.0
acos0028 acos -0.001 0.0 -> 1.5717963269615634 -0.0
acos0029 acos -0.001 -0.0 -> 1.5717963269615634 0.0
acos0030 acos -0.57899999999999996 0.0 -> 2.1882979816120667 -0.0
acos0031 acos -0.57899999999999996 -0.0 -> 2.1882979816120667 0.0
acos0032 acos -0.99999999999999989 0.0 -> 3.1415926386886319 -0.0
acos0033 acos -0.99999999999999989 -0.0 -> 3.1415926386886319 0.0
acos0034 acos -1.0000000000000002 0.0 -> 3.1415926535897931 -2.1073424255447014e-08
acos0035 acos -1.0000000000000002 -0.0 -> 3.1415926535897931 2.1073424255447014e-08
acos0036 acos -1.0009999999999999 0.0 -> 3.1415926535897931 -0.044717633608306849
acos0037 acos -1.0009999999999999 -0.0 -> 3.1415926535897931 0.044717633608306849
acos0038 acos -2.0 0.0 -> 3.1415926535897931 -1.3169578969248168
acos0039 acos -2.0 -0.0 -> 3.1415926535897931 1.316957896924

je ne sais pas si je suis claire!!
merci pour vos nombreuses reponses

[rambc]

Dans la mesure où les tests unitaires se font via des classes, rien ne t'empêche de lire un fichier texte écrit par des non informaticiens pour le traiter au sein de ta classe test. Non ?

[wiztricks]

Salut,

en fait le but n'est pas de faire des testes unitaire mais d'exécuter des fonctions , et on doit être capable de rajouter des centaines ou millier de testes a la main pour chaque fonction , et je vois mal un non informaticien écrire du code python

Soit vous livrez des "fonctions" et l'utilisateur a quelques compétences Python. Soit vous livrerez une application dont le bon fonctionnement dépendra de ces fonctions et dans ce cas, il s'agit de tests "unitaires".
C'est une question de "terminologie".

Indépendamment de la terminologie, on ne s'amuse pas à "tester" on le fait pour être confiant sur les qualités du composant (fonction, module, application,...) qu'on livre, qu'on va utiliser,....

Dans votre cas, je ne vois pas trop comment établir que la fonction "truc" aura été correctement testée ou pas.
Ce n'est pas une fonction du nombre de tests et encore moins du temps que pourra passer le client à inventer nombre de tests qui ne seront peut être pas pertinents.
Comment "bien" tester découle d'un qualitatif établit dans ce qu'on appelle "plan de test" et s'il s'agit de simples fonctions, çà dépendra beaucoup des algorithmes qu'elles implémentent - et il faut du savoir faire d'informaticien.

Peu importe... on peut supposer que cette démarche résulte d'obligations légales ou contractuelles et donc propres à un contexte assez "particulier".

Quelque part vous voulez construire une sorte de base de données de "points" de tests et automatiser leur exécution.

Si cette base de donnée est un fichier texte, du style:

acos0000 acos 0.0 0.0 -> 1.5707963267948966 -0.0
acos0001 acos 0.0 -0.0 -> 1.5707963267948966 0.0
acos0002 acos -0.0 0.0 -> 1.5707963267948966 -0.0

Il va falloir l'analyser pour:
1 - récupérer la fonction, les paramètres passés, les résultats attendus.
2 - transformer les "strings" en variables du type attendu,
3 - exécuter l'appel à la fonction
4 - valider le résultat,
5 - passer au point de tests suivant.

Rien d'insurmontable:
- un regexp pour séparer l'appel des résultats, i.e. transformer:
"acos0000 acos 0.0 0.0 -> 1.5707963267948966 -0.0" en deux strings
fct_point = "acos0000 acos 0.0 0.0"
fct_result = "1.5707963267948966 -0.0"
- fct_point.split pour séparer nom du test, fonction, paramètres
- un peu de magie pour savoir que "acos" attend deux paramètres de type float,...
- encore de la magie pour savoir le type du résultat attendu...
Pour le reste vous savez déjà le faire: voir le post.

En fait les points les plus délicats sont 1 et 2 et portent sur la qualité des informations entrées dans le fichier texte car il faudra du "méta" associé à chaque fonction testée pour valider type et valeurs des paramètres, des résultats.

Après on a des questions incidentes:

• Imaginez que passer l'ensemble des tests dure 3 jours,
• Oops, çà plante pour une donnée pourrie dans le fichier au bout de 2,5 jours

Ce n'est pas votre faute: c'est le client qui a construit le fichier.
Mais si vous travaillez au forfait, il faudra peut être rephaser le planning car certaines activités seront en suspend dans l'attente du résultat... Et comme les "tests" sont plutôt sur la fin, le chef de projet aura des soucis.

Un fichier "plat" n'est peut être pas la structure la plus appropriée pour:
- valider que les tests ajoutés ont été correctement écrit,
- fractionner le passage des tests,
- stocker des informations sur leur passage

Ceci dit comme l'a déjà souligné rambc, cela n'exclut pas l'utilisation d'un framework de test existant.
- W