En regardant le code je ne vois pas d’où ça peut venir.
J’ai essayé de mettre des logs dans le runtime (il y a une fonction substrate pour ça) mais il faut trouver la bonne commande pour récupérer le log (normalement c’est facile mais en mode test le -- --nocapture ne suffit pas).
Par rapport au débug par print, je pense qu’on ne sait pas utiliser les “bons outils”, c’est-à-dire un débugger comme le fait @cgeek, et que ça pourrait aider pour ce genre de cas.
La différence de comportement entre le test unitaire et test d’intégration me chagrine un peu 
J’utilisais le débuggeur intégré de VSCode mais entre VSCodium et les différentes extensions Rust qui ne marchent jamais complètement, ça ne marche plus. Et puis dans le test d’intégration il faut débugger du WASM donc encore un outil différent.
Je voulais juste afficher la payload juste avant signature pour comparer.
Je crois que ce que fait Cedric est d’utiliser le runtime natif plutôt que wasm pour pouvoir débugger dans CLion. Je vais ajouter ce point à l’ODJ de la prochaine visio dev pour qu’il nous montre comment ça marche.
Je peux vous le dire tout de suite si ça peut aider :
--dev --tmp :
node/src/chain_spec.rs:107 :
Si le Runtime est lancé en natif, vous pouvez également placer des points d’arrêt dedans. Pour les tests d’intégration c’est plus compliqué : je suppose qu’il faut lancer Duniter en mode Debug à part et modifier le code source du TI pour que celui-ci ne le lance plus et ne scrute pas ses logs. Mais je n’ai jamais essayé de le faire.
Jetbrains a récemment sorti un IDE dédié à Rust : RustRover. Pour l’instant je ne l’utilise pas, j’ai eu quelques soucis de coloration syntaxique avec donc je ne vous le conseille pas pour l’instant. Mais vous pouvez l’essayer.
En tout cas, le Debug devrait aussi fonctionner dans VSCode, mais je ne suis pas familier de cet outil.
Même chose que précédemment, mais la commande à rentrer est :
test -p duniter-end2end-tests --test cucumber_tests
Résultat avec un point d’arrêt dans cucumber_tests.rs :
En revanche, cela ne permet pas de mettre de point d’arrêt dans le Client (comme je le disais ci-dessus).
Eh bien ça va devenir simple puisque j’en ai eu besoin pour déboguer les tests end2end, c’est trop long de comprendre ce qui se passe sans point d’arrêt.
J’ai ajouté une option --no-spawn sur ma branche, qui s’utilise comme suit :
cargo cucumber -i "identity*" --no-spawn
A côté il faut simplement avoir lancé un nœud en mode Debug, par exemple avec :
export DUNITER_GENESIS_DATA=./end2end-tests/cucumber-genesis/default.json
export DUNITER_GENESIS_CONFIG=./end2end-tests/cucumber-genesis/default.json
cargo cucumber-node