unittest : connaître le dernier test qui pose problème

Bonjour,
pour le moment j'utilise le code ci-dessous pour des tests unitaires.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class MathFormulaGoodInput(unittest.TestCase): good_formulas = [ # SIMPLE THINGS '3**x**2', '(3+2)**[x+5]**{2-4}', '(1+5)/(7-5)', # FUNCTIONS 'cos x', 'cos(x)', ] def test_good_formula(self): print('') for oneGoodFomula in self.good_formulas: print('\t--> ' + oneGoodFomula) self.assertIsNotNone(mathFormula.parser(oneGoodFomula))
Ce code me permet de connaître la formule qui pose problème, c'est la dernière affichée. Malheureusement, cela a l'inconvénient de tout afficher donc quand il y aura plein d'autres tests, ce qui va arriver très vite, cela ne sera pas fonctionnel.

Ma question. Peut-on demander à unittest de donner juste la formule qui ne répond pas au test ?

Une autre idée serait d'écrire un fichier log mais j'aimerais mieux que tout passe par la console.

Salut,
Les self.assertXXX acceptent généralement plusieurs paramètres dont le dernier optionnel est le message à afficher lorsque le test 'plante', genre:

Code:

self.assertIsNotNone(mathFormula.parser(oneGoodFomula), '\t--> ' + oneGoodFomula)

- W

Merci pour cette info.

J'ai essayé sans succès. Le message n'apparait pas.

En attendant je vais utiliser l'horreur suivante :
Code:

1 2 3 4 5 try: self.assertIsNotNone(mathFormula.parser(oneGoodFomula)) except: print('\t--> ' + oneGoodFomula) self.assertIsNotNone(mathFormula.parser(oneGoodFomula))
Il y a doublon dans le message d'exception levée mais à choisir, je préfère cela aux centaines de chaînes que j'aurais à tester.

En fait, je vois ce qui ne marche pas. Dans mon cas, je propose des formules et mon programme comporte un bug qui doit être repéré.

Une idée ?

Salut,

La question est de savoir ce qu'est supposé retourner
mathFormula.parser(oneGoodFomula)
lorsque çà se passe "mal".

Si on dit "çà se passe bien si le retour is not None", dans le cas contraire, la formule est à priori invalide et l'afficher pour savoir laquelle semble raisonnable.
Si on dit, "çà se passe bien ou çà lève une exception"... ben c'est autre chose...
Mais c'est toi qui voit...

Vu de loin, il faudrait peut être réfléchir au plan de test: empiler des entrées pour voir ce que çà donne n'est pas une bonne structure pour s'assurer que "parser" fait ce qu'on attend de lui dans les différents cas...
Note: en test unitaires, les différents cas dépendent de son implémentation. En test fonctionnels, ca dépendra plutôt du cahier des charges. Ici, j'ai l'impression qu'on est entre les deux...
- W

Citation:

Envoyé par wiztricks

La question est de savoir ce qu'est supposé retourner mathFormula.parser(oneGoodFomula) lorsque çà se passe "mal".
...
Si on dit, "çà se passe bien ou çà lève une exception"... ben c'est autre chose...

En fait, j'ai besoin dans un premier temps de vérifier que les derniers changements dans mon code continuent à traiter correctement mes formules, ceci ne veut pas dire que ce qui est produit par mathFormula.parser est bien juste. En fait, c'est juste pour repérer les gros bugs.

Concrètement, mathFormula.parser produit un arbre d'une formule, arbre non adapté à la production de tests unitaires, d'où ma demande un peu particulière.

Citation:

Envoyé par wiztricks

Vu de loin, il faudrait peut être réfléchir au plan de test...

Une petite sieste réparatrice plus tard, je suis arrivé à ce que je voulais avec l'astuce suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 class GoodError(ValueError): pass def TestGoodFormula(oneGoodFomula): try: mathFormula.parser(oneGoodFomula) eveythingSeemsOk = True except: print('', ' --->> ' + oneGoodFomula + ' <<---', sep = '\n') eveythingSeemsOk = False if eveythingSeemsOk: raise GoodError class MathFormulaGoodInput(unittest.TestCase): good_formulas = [ # SIMPLE THINGS '1,4', '(7)', '4+7', '(x) + 4', '(-2x + 4)', '3**x**2', '(3+2)**[x+5]**{2-4}', '(1+5)/(7-5)', # FUNCTIONS 'cos x', 'cos(x)', 'cos(x+4)', ] def test_good_formula(self): sys.stdout.write('') for oneGoodFomula in self.good_formulas: self.assertRaises(GoodError, TestGoodFormula, oneGoodFomula)
Ceci me permettra de vérifier mon code sur des formules sans erreur. Je viens de mettre cela en route, et cela m'a permis de repérer une régression suite au changement du code d'une fonctionnalité. C'est exactement ce genre de choses que je voulais faire.

Plus tard, je vérifierais que l'arbre produit n'est pas délirant de façon indirecte car j'ai un module qui partant de l'arbre produit par mathFormula.parser produit une version texte. Je pourrais alors faire des tests unitaires sur ces bonnes formules.

Salut,

Citation:

Concrètement, mathFormula.parser produit un arbre d'une formule, arbre non adapté à la production de tests unitaires, d'où ma demande un peu particulière.

J'espère que tu te rends compte que tu es en train de dire que 'parser' n'a pas été construit pour être testable...
- W

Citation:

Envoyé par wiztricks

J'espère que tu te rends compte que tu es en train de dire que 'parser' n'a pas été construit pour être testable...

Oui mais...
... comme indiqué avant, je vais pouvoir tester indirectement ce code. De plus, le code de 'parser' a été éclaté en plein de petites fonctionnalités dont il est très facile de vérifier le bon fonctionnement.
... l'arbre produit par 'parser' est par nature complet et compliqué. C'est ceci qui rend difficile un test automatisé. Par exemple, pour la formule "cos(x)", la fonction 'parser' renvoie un dictionnaire du type suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 {'arguments': [{'canBeAVariable': True, 'hasVariables': False, 'isLitteral': True, 'isSimplified': True, 'kindOfObject': 'number', 'set': 'unknown', 'stringFormula': 'x'}], 'canBeAVariable': False, 'default': 'z', 'domain': '¨C', 'gabaritForVariables': {'contextMaxNumber': 1, 'contextMinNumber': 1, 'contextVariables': [{'variableMaxNumber': 1, 'variableMinNumber': 1}]}, 'hasVariables': True, 'isSimplified': False, 'kindOfObject': 'function', 'set': '¨C', 'stringFormula': 'cos', 'variablesDelimiters': '(?)'}
De toute façon, je pense que tester un parser n'est pas une chose simple. C'est la nature même du problème qui rend les choses difficiles.

Ceci étant dit, quand je nettoierais mon code, j'essaierais de voir comment faire en sorte d'améliorer le test du parser.

Si quelqu'un a des idées générales à proposer, je suis tout de même preneur...