Gordon, who’m’st migrating utilise witches.town. Vous pouvez læ suivre et interagir si vous possédez un compte quelque part dans le "fediverse".

@CobaltVelvet Je comprends pas, c'est quoi le problème ?

@CobaltVelvet Si tu veux accéder à la RequestException originale, tu peux faire "except BaseNomadException as e" et utiliser e.__context__

@val ben ça m'emmerde, ça devrait être passé à l'exception au lieu de me donner un BaseException(None)

@CobaltVelvet mais du coup le __context__ ça résout ton problème, non ?
'fin c'est la façon standard de "re-lancer" une exception en Python 3.

@val ça résoud mon problème mais c'est pas assez évident pour que je l'ai à temps :/

@val la solution :/ un argument c'est évident et c'est dans le __str__/__repr__, récupérer l'exception et .__context__ non

@CobaltVelvet Si c'est pour l'afficher, tu peux utiliser traceback.print_exception(e, e, e.__traceback__)

@val oui mais je veux pas coller ça dans tous mes tests pour pas rater le contenu des exceptions

@CobaltVelvet Euh mais normalement ça doit être affiché par défaut dans les tests.
Tu utilises quoi comme lib de tests ?

@CobaltVelvet c'est de la merde nose pour rapporter les erreurs

@val j'ai jamais réussi à lui faire appeler un truc avant tous les tests

@CobaltVelvet avant chaque test, ou avant tous les tests ?

@val avant et après tous les tests

c'est pour préparer les base de donnée une seule fois et avoir une transaction pour chaque test

@CobaltVelvet euh mais t'es pas censée partager la même bdd entre tous les tests (sinon les tests risquent de planter selon l'ordre d'exécution)

Gordon, who’m’st migrating @gordon

@val @CobaltVelvet si chaque test est encapsulé dans une transaction, ça pose pas de problèmes, c’est ce que fait Django.

Pour exécuter du code avant et après chaque test, tu as les méthodes setUp et tearDown (et vive la pep008) à surcharger