Plan de migration

[cgeek]

Comme je l’évoquais dans ce message, je compte bien démarrer la migration de Duniter vers sa version dite « V2S » (Duniter V2 basée sur Substrate).

Je vous propose un plan pour cette migration, basée sur 3 étapes.

Etape 1 : le protocole

C’est l’étape la plus fondamentale, qui consiste à réécrire le protocole Duniter pour être compatible avec Substrate.

Pour quoi faire ? Il s’agit essentiellement d’un travail de définitions, afin de lever toute ambiguïté pour le développement de l’implémentation et donc d’éviter de potentiels bugs. A ce niveau nous prenons de la hauteur, afin de discerner l’essentiel de ce qui relève du détail d’implémentation. On peut parler de spécification.

Ainsi dans le protocole nous ne verrons pas de notions telles que Rust, RocksDB ou autres pallet. Toutefois comme ce protocole vise à permettre une implémentation Substrate, celui-ci va fréquemment en reprendre certaines définitions (ex. : les Storage, Trie, Merkle root, Runtime, …).

Je compte investir le plus gros de mon temps dans cette étape. Vous pouvez bien entendu participer si vous le souhaitez, je compte commiter sur le dépôt documents/rfc et discuter de son évolution dans cette catégorie du forum.

Etape 2 : l’implémentation

C’est le développement proprement dit, qui consiste à matérialiser le protocole en code exécutable via Rust et le framework Substrate.

Il s’agit certainement de l’étape la plus longue et la plus difficile, même si le framework Substrate devrait grandement aider. Dans cette étape seront également codés tous les tests automatisés (unitaires et fonctionnels).

Là, il va falloir trouver des développeurs je ne compte pas vraiment m’investir dans cette tâche, ne serait-ce que par manque de temps. Mais aussi je souhaite passer la main à d’autres individus talentueux et enthousiastes à l’idée de propulser la Ğ1 à un tout autre niveau.

Etape 3 : l’interfaçage

J’ai souhaité distinguer cette étape de la n°2. Il s’agit certes de développement de l’implémentation Duniter V2S, néanmoins cette partie n’est pas dans le protocole.

Il s’agit ici de code d’intégration avec d’autres composants à destination des clients : Cesium, Ğecko, Tikka, Silkaj, WotWizard, Remuniter, ğchange, etc. ; mais aussi de l’outillage pour s’interfacer avec et migrer les monnaies existantes Ğ1 et ĞT.

J’estime cette partie suffisamment volumineuse pour être à part, mais aussi je préfère opérer une séparation avec le cœur afin qu’il soit clair pour les développeurs Duniter que cette partie ne puise pas directement dans le Storage (ce dernier étant optimisé pour l’exécution du protocole, pas pour la lecture des clients), et que la migration des Ğ1 et ĞT est encore un autre sujet.

Un planning ?

Difficile d’en donner un, les contributions étant libres. De mon côté j’ai encore une partie du mois de décembre pour produire le protocole, je ne sais déjà pas si cela sera suffisant. De plus nous allons devoir prendre des décisions de rupture avec le protocole DUBP de Duniter, ce qui génère de l’incertitude planning :

• protocole de production de blocs : BABE ? PoW de Duniter ? Hybride ? Autre ?
• protocole de gouvernance : quel algorithme pour accepter une évolution du protocole ?
• protocole de résolution de forks (finalisation) : GrandPa ? Duniter 3-3 ? Autre ?
• …

J’en omet certainement, je n’ai pas encore tout creusé.

Voilà pour un aperçu de ce qui nous attend pour ces prochains mois j’espère que vous en serez !

[Nechrom]

@cgeek

Substrate

Salut. Donc substrate est un langage de développement de blockchain, vous développez une nouvelle blockchain et vous migrez les données de l’ancienne? Pensez vous que nous pourrons utiliser les wallets type Metamask Trust ou autres?

[tuxmain]

Le plan initial était de migrer les données autant que possible. Mais ce n’est pas pour tout de suite.

Quelle est la caractéristique des wallets Metamask ?

Passer à Substrate va sûrement faciliter les interactions avec les autres cryptomonnaies, puisqu’on pourra profiter de l’écosystème de grosses cryptos qui sont sur le marché financier.

Après ça dépend de ce qu’on appelle « utiliser des wallets ». A priori la G1 restera une monnaie à part entière et non une énième surcouche d’Ethereum. La spéculation monétaire m’intéresse fort peu donc je n’y connais pas grand chose, mais s’il y a interaction je ne vois que l’atomic swap.

[cgeek]

@tuxmain

Le plan initial était de migrer les données autant que possible.

Oui, précisément. Bien que pour l’instant je ne vois pas ce qui serait impossible à migrer.

Quant aux évolutions du protocole, elles vont venir dans un second temps (bien que certaines soient obligatoires dès le début, ne serait-ce que les formats de données). Gérer de nouveaux types de wallet n’est pas prioritaire à l’heure actuelle, mais ça va venir, à n’en pas douter.

L’une de mes motivations à cette migration est de permettre à la Ğ1 d’intégrer des marchés de change, afin de créer un pont vers les économies existantes.

[Nechrom]

Ok, c’est une bonne nouvelle que de migrer vers l’écosystème des cryptos. Même si le travail me semble colossale pour un seul homme, surtout en conservant le protocole de toile de confiance. Si cela s’avère pertinent je peux aider sur un point, créer une crypto tampon avec transfert manuel. Utilisable durant la migration via les wallets standard.

[cgeek]

Ce n’est pas très compliqué avec Substrate, et puis je ne suis pas tout seul

En vérité plus j’avance et plus je trouve qu’implémenter et migrer la Ğ1 sera simple. Nous verrons si cette hypothèse se confirme ces prochaines semaines.

[elois]

Concernant ce plan de migration que je découvre aujourd’hui, je suis personnellement incapable de suivre l’approche consistant à d’abord tout théoriser, et ce n’est pas de cette manière que l’on procède dans mon boulot UNL (je travaille pour une crypto utilisant substrate).

Ce que je propose, c’est de continuer ma PoC à mon rythme, avec les contributeurs qui veulent bien m’y aider, et au fur et à mesure que l’on avance dans cette PoC, ça permettra de confirmer ou infirmer ce qu’il est possible d’implémenter, et de voir comment implémenter au plus simple.

Je suis d’accord pour discuter en parallèle du nouveau protocole, mais je n’aurais pas le temps de participer à tous les échanges, ni de répondre à tous les questionnements qui suivront mes avis, car je préfère consacrer le peu de temps libre que je peux dégager pour la Ğ1 à coder.

Aussi, quelques échanges vocaux vont bien plus vite que de long échanges écris, je préfère donc faire une visio de temps en temps plutôt que de participer à des interminables débat écris.

---

Voici un plan de migration approximatif que j’ai en tête à l’instant t en ce 10 janvier 2022, il peut changer totalement dans les semaines et mois à venir, en fonction de nos échanges et de l’expérience apportée par la PoC:

1. Remplacer AURA par BABE
2. Développer la sous-toile forgeron
3. Développer la logique offchain qui vérifie la règle de distance, avec système similaire à une sorte d’oracle pour l’injection onchain du résultat
4. Benchmarker les « poids » de tout les extrinsics
5. Créer une chain spec pour une 1ère monnaie Ğtest substrate sans migration
6. Développer l’écosystème autour de cette monnaie de test (clients, indexers, systèmes de stockages de données utilisateur).
7. Coder un outil permettant de convertir un state Duniter v1 en chain spec pour duniter v2.
8. Migrer la Ğtest
9. tester intensivement la Ğtest migrée, vérifier que tout à bien été migré
10. Faire une migration à blanc de la Ğ1 (une sorte de fork de la Ğ1 qui sera supprimée après quelques semaines ou mois de tests)
11. Refaire des migrations à blanc si besoin, jusqu’à ce que l’on soit suffisamment confiant pour réaliser la vraie migration.
12. Migrer la Ğ1

Volontairement je ne détaille pas, certains points nécessitent de longues explications que je ferai plus tard quand je trouverai le temps (peut-être seulement en visio si trop long à l’écrit).
Je n’ai pas inclus dans ce plan toute la partie communication avec les utilisateurs, qui sera essentielle à bien préparer en amont, mais ça ne sert à rien de communiquer trop tôt, je pense pas avant l’étape 8 ou 9.
Je n’ai également pas parlé de toute la partie « coder des tests automatisés », il faudra évidemment couvrir le code de tests automatisés le plus possible, c’est un travail long et chiant mais indispensable pour avoir quelque chose qui tienne la route.

Ne me demandez pas de dates, je n’en sais rien moi-même, ça dépendra de combien on sera, du temps que chacun pourra y consacrer, et de l’ampleur des problèmes techniques que l’on rencontrera.

J’aurais probablement de nouvelles absences plus ou moins longue, mais j’espère qu’avec ou sans moi cette migration finira par advenir !

[cgeek]

Je viens de pusher la mise à jour du premier draft du protocole pour Duniter v2.

Rien de sensationnel, néanmoins on peut déjà identifier les extrinsics spécifiques Duniter à développer :

• Dubp.identity()
• Dubp.revoke()
• Dubp.certify()
• Dubp.adhere()
• Dubp.produce_ud()
• Dubp.transfer()
• Dubp.set_keys()

J’ai réécrit toutes les règles du protocole qui avaient encore un sens, et dans le contexte Substrate et sa logique de comptes. Mine de rien, on passe de ~2900 lignes à ~1200. Jolie diète.

Bon, il reste 56 TODOs dedans, sans parler des autres pour lesquels il faut que je fasse un tri en local.

Mais ça fait déjà une bonne base sur laquelle discuter.

[elois]

@cgeek

Rien de sensationnel, néanmoins on peut déjà identifier les extrinsics spécifiques Duniter à développer :

• Dubp.identity()
• Dubp.revoke()
• Dubp.certify()
• Dubp.adhere()
• Dubp.produce_ud()
• Dubp.transfer()
• Dubp.set_keys()

Voila c’est exactement ce que je pense qu’il ne faut pas faire, en réalité on aura beaucoup plus d’extrinsics que ça, et pas préfixé Dubp., mais réparti dans différentes pallets, pour que l’implémentation reste modulaire et évolutive.

Par exemple, rien que pour la pallet Identity, j’ai 9 call, et je n’ai pus me rendre compte que j’en avais besoin que en faisant l’implémentation:

create_identity()
confirm_identity()
renew_identity()
validate_identity()
validate_identity_and_add_rights()
add_right()
del_right()
set_right_subkey()

Je suis parti sur un concept de droits qui est beaucoup plus souple et évolutif. Chaque identité à des droits (droit de créer le DU, droit de certifier, etc).
Une identité qui na’ plus aucun droit est automatiquement supprimée après une période paramétrable (MaxNoRightPeriod).

Dans ce système, il n’y a par exemple plus de révocation, à la place on supprime tous les droits de l’identité, qui sera alors inactive, et supprimée définitivement au bout de MaxNoRightPeriod blocs.

Je peux spécifier formellement ce que j’ai codé, mais ça me semble beaucoup trop tôt, car ça peut encore beaucoup bouger selon les retours d’expérience que vous ferez quand vous utiliserez la 1ère monnaie de test.

Je pense qu’on y gagnerait tous à piloter le projet comme une start up, en cherchant à rester agile et nous adapter à l’expérience, plutôt qu’à vouloir figer des spec.

Il me semble que ça apporterait beaucoup plus de choses aux utilisateurs de la Ğ1, hors c’est eux ma motivation première, et non pas un protocole.

Tu veux m’aider @cgeek ? Alors stp oubli ces spec et rentre dans le code, aide-moi à avancer suffisamment pour lancer une 1ère monnaie de test, ce sera beaucoup plus utile

[cgeek]

Bon il y a trop de choses à réfuter ici, je laisse tomber.

Je suis lassé de nos divergences d’opinions, et cette proposition de développement improvisé ne me convient pas. Ce sera sans moi, advienne que pourra.

[tuxmain]

On peut pas trouver un compromis entre ces deux méthodes ? Genre avancer sur le code là où des specs précises ne sont pas absolument nécessaires au début, pour savoir où on peut aller. Avancer sur les specs mais pas forcément dans le détail, pour savoir où on veut aller. Réviser les specs au besoin et jeter du code si il faut recommencer un bout. Le code perdu c’est toujours de l’expérience en plus.

Une feuille de route assez précise, pour un contributeur non expert, ça peut être rassurant.

Bref je pense a priori que le projet peut supporter qu’on ne suive pas tous une même méthode de travail à fond, et que c’est peut-être plus productif si ça permet de travailler ensemble et de ne pas décourager les contributeurs.

C’était le message naïf-bisounours-pas-de-problème-que-des-solutions.

[1000i100]

Moi aussi la voie du compromis me semble pas mal :
L’intérêt que je vois à avoir des spec, c’est que pour paralléliser le boulôt, chacun peu s’occuper d’une partie différente, et comme le dit tuxmain, c’est rassurant si on maitrise mal le projet.
L’inconvénient des spec, c’est, c’est que ça donne l’impression qu’on sait où on va et donc qu’il est plus difficile d’accepter de changer quand on se rend compte que c’est une fausse route.

Comme tu le disais @cgeek le plus long, c’est l’implémentation, du coup, c’est tentant de faire la conception en amont via les spec, et dans les grande ligne, ça me semble utile pour ne pas être totalement à l’aveugle. En revanche, je me méfie des spec précises. Si ça deviens le cahier des charges des bons vieux projets menés en cycle en V, le taux d’échec est colossal : 3 % de réussite, 42 % d’échec total sur les gros projets.
Source : CHAOS Report 2015

Une approche itérative et agile, plus exploratoire (comme le propose @elois) montre de bien meilleur résultat, encore plus si l’on arrive à modulariser suffisamment pour gérer plusieurs petits projets : 58 % de réussite, 4 % d’échec.

Ceci dit l’exploratoire sans filet de test, c’est du code jetable qui s’il n’est pas jetté assez vite deviens du code explosif. Et j’ai peur qu’avec le manque de ressources en temps de développeur que nous avons, si les tests ne sont pas ajoutés au fur et à mesure voir idéalement en amont (approche TDD Test Driven Developpement ou BDD Behavior Driven Design) la nouvelle mouture de Duniter ne soit pas plus stable que l’ancienne voir moins. Du coup, il me semble essentiel de produire du code tester soit dès les phases d’exploration à l’aveugle (TDD), soit au moins d’avoir une couverture de test fonctionnelle à défaut d’unitaire pour s’assurer que ce qui marche continue de marcher à chaque évolution du code.

• Du coup, avoir un Livre blanc qui décrit dans les grandes lignes les concepts clef de Duniter me parait pertinent, sans aller au degré de précision d’une spec.
• Avoir une distinction des différents métiers pour en faire des modules les plus indépendants possible les un des autres me semble pertinent (par exemple métier WoT, métier monétaire, métier consenssus/blockchain…)
• Avoir au moins quelques tests fonctionnels clef prêts pour chaque module, par exemple façon cucumber.io pour les rendre le plus lisible possible en tant que documentation/spec et avec une abstraction vis-à-vis du code qui évite d’avoir à maitriser Rust pour les rédiger. (Mais là encore, pas besoin d’en écrire trop tant qu’il n’y a pas de code derrière si on ne veut pas avoir à les réécrire 15 fois)
• Avoir débroussaillé l’état de l’art là où il est possible d’anticiper qu’il y aura des choix techniques à faire (Aura vs Babe, GrandPa et autres…) pour avoir une synthèse des avantages et inconvénient quand le moment de trancher sera venu coté implémentation.
• Implémenter, par essai erreur comme toujours, et au plus tard dès qu’on s’apprête à passer à un autre morceau, vérifier que s’il y a des tests fonctionnels associés à ces métiers, ils passent, et s’il n’y en a pas, les rédiger, les faire échouer, puis passer. Idéalement développer en TDD pour avoir une couverture unitaire de 100% sur les aspects métier.
• Puisque @cgeek tu distingues l’interfaçage, je vais aussi me prononcer là-dessus. L’approche CQRS me semble adapté au découplage entre le coeur blochain (orienté écriture) et les besoins clients (orienté lecture). En gros, la partie Duniter n’a pas besoin d’implémentation spécifique pour les clients. En revanche, des proxy (comme les pod Cesium+) peuvent s’y abonner à des noeuds (donc comme s’il était des noeuds classiques, demander une syncro, puis recevoir les nouveaux blocs, et émettre/transmettre des documents) pour construire leur propre base de données conçu non pas pour les usages blockchain mais pour les clients. Et donc avoir une api plus adapté à ces usages, des indexations adaptées, et sans besoin d’être 100% trustless (avec un proxy qui se contente de vérifier que plusieurs nœuds au hasard lui envoient les mêmes infos peut suffir). Avec cette approche, on libère Duniter du besoin de gérer les api clients, et c’est un métier à part qui s’en charge.

Dans mon rêve le plus fou, avec cette approche, on peut commencer en parallèle livre blanc avec descriptions des différents métiers, implémentation et test fonctionnels…
Et très vite, voir peut-être aussi dès maintenant pour la partie substrate, l’implémentation de proxy destiné à fournir une api client gva, elastic search ou assimilé.

Le tout avec de quoi avancer dans sa zone de confort (implémentation pour @elois , description du fonctionnel pour @cgeek) sans que ce soit opposé.

En bonus pour anticiper les décalage par rapport à la vision initial, un article sur les matrices de compromis : La matrice des compromis : en cas de problèmes, qu’ajusterons-nous ?

Dans notre cadre, coût correspondrait plus à motivation/énergie consacrée au code et délais au temps et à la disponibilité des dev… Mais je trouve intéressant d’avoir à l’idée qu’avoir le périmètre fonctionnel comme variable d’ajustement permet d’avancer bien plus surement que de le figer. Au contraire de la qualité qui si on la néglige nous explose à la figure ensuite.

Selon moi, une des possibilités hors implémentation de D2S serait d’identifier ce qui dans substrate peut déjà être utilisé pour synchroniser des proxys aux futurs nœuds, et ainsi n’avoir qu’à compléter avec ce qui nous sera spécifique et donc pouvoir commencer l’implémentation de proxy et de leur api client pour que cesium2, gecko et silkaj puisse au plus vite s’y adapter.

Bonus : L’extrait de propale perso sur lequel je me suis appuyé pour certains éléments dans ce long message.

[elois]

Je suis d’accord avec le fait de tester dès le début, et j’ai déjà commencé à le faire, j’ai travaillé sur cucumber et intégré 2 tests fonctionnels: integration-tests/features/balance_transfer.feature · master · nodes / rust / Duniter v2S · GitLab

Ça fonctionne en local, mais pas encore dans la CI, il faut que je trouve pourquoi.

Ma PoC c’est déjà l’implémentation, je l’ai codée de la manière la plus propre possible dès le début, et de manière testable. Au niveau spectre fonctionnel je couvre déjà la quasi-totalité des fonctionnalités métier de Duniter v1, il me manque uniquement:

• La règle de distance
• La révocation explicite d’une identité

et c’est tout !

Je vais donc prioriser ces prochains jours le fait de couvrir l’existant de tests fonctionnels, puis d’implémenter ces 2 fonctionnalités manquantes.

Notez que, avant de pouvoir inclure la règle de distance, je dois déjà implémenter BABE, car le système d’oracle à mettre en place aura besoin de se reposer sur BABE pour connaitre la liste des autorités.

Ensuite je souhaite également implémenter la sous-toile forgeron, ce qui sera rapide, car j’ai codé la pallet certification en tant que pallet instantiable, donc j’aurais juste à configurer une nouvelle instance et implémenter les différents handler.

Personnellement je sais ou je vais et ce qu’il y a à faire, et je vais essayer de prendre du temps pour l’écrire dans les tickets du board et dans un nouveau sujet sur ce forum, mais ça restera très macro, je ne compte pas faire de spec formelle, ce qui n’empêche pas de discuter des détails d’implémentation dans les tickets, comme je viens de le faire ici par exemple: Make UD creation manual (extrinsic claim_uds) (#11) · Issues · nodes / rust / Duniter v2S · GitLab

En revanche, je n’écrirais pas de spécifications formelles précises, et ne me conformerais pas à d’éventuelle spécification formelles précises rédigées par d’autres, car outre que j’en suis incapable, je pense que ce serait nuisible à ce stade, et je ne suis même pas convaincu que ce soit nécessaire à terme.

Depuis 6 mois je travaille à plein temps pour un projet comportant 2 crypto-monnaies, et nous n’avons pas de spécification formelle, alors que l’une de nos crypto-monnaies (moonriver) est déjà en production depuis 6 mois et compte déjà plusieurs millions de transactions, il y a beaucoup de monnaie en jeu (plusieurs milliards d’UNL), des gros investisseurs, la nécessité d’être ultra stable et les enjeux en cas de problème sont infiniment plus grave que pour la Ğ1, avec beaucoup plus de fonctionnalités et des fonctionnalités plus complexes, et c’est très stable depuis 6 mois.

Ce qui fait la stabilité c’est une excellente couverture des scénarios métier par de nombreux tests fonctionnels (ou end2end), et ça je compte bien dessus.

En revanche, je pense que des spec précise ne sont pas nécessaires, et sont même nuisible, car ceux qui codent devrait alors concentrer davantage leur énergie à se conformer a des spec qui sont à côté de la plaque plutôt qu’a répondre au besoin métier.

Bref, si quelqu’un veut faire un bilan des décisions prises dans nos discussions sur ce forum, ou/et lister les fonctionnalités métier que l’on veut (en restant macro, sans se soucier du comment), voir écrire des scénarios de tests cucumber, tout ça m’est très utile, je prends à bras ouvert

Par contre, je ne me conformerais pas à des specifications formelles, ceux qui veulent en écrire devront coder eux-mêmes ure autre implémentation, ou trouver quelqu’un pour le faire, mais ce ne sera pas moi.

[Pini]

Quitte à parler d’agile, pourquoi pas essayer d’en faire un peu ?

Des sprints de 15 jours. Une audio en début de sprint pour fixer les objectifs. Une audio fin de sprint pour faire valoir le REX.

Les spec sont importantes aussi. Il faudrait les mettre à jour au fil des sprints et des prises de décision.

[elois]

Je suis bénévole et j’ai un boulot à temps-plein à côté donc perso je peux pas m’engager sur un « sprint » tout les 15 jours, mes dispo étant très variables et ma motivation aussi.
Je veux pas non plus qu’on s’enferme dans une méthode trop codifiée, par contre je pense que c’est une bonne idée de faire des visio régulières, reprendre les « visio mensuelles des contributeurs techniques » serait déjà un très bon début.

On peut aussi envisager une 2ème visio plus resserrée autour des contributeurs directs à duniter-v2s itself, et donc plus facile à organiser car comprenant moins de personne, ça peut me convenir à condition que ce soit systématiquement un Samedi ou Dimanche

[kimamila]

@cgeek

Bon il y a trop de choses à réfuter ici, je laisse tomber.

Je suis lassé de nos divergences d’opinions, et cette proposition de développement improvisé ne me convient pas. Ce sera sans moi, advienne que pourra.

non, ami, ne te fache pas. Je penses que ta méthode n’a pas besoin d’être validé par nous. Simplement, si tu y crois, il faut continuer. Cela apportera quelque chose, même si Elois avance de son côté d’une autre manière.
Il peut en effet y avoir 2 visions qui avancent, et une convergence plus tard (ou pas = un ralliement). Un fork méthodologique quoi.

Concernant les points que tu veux réfuter, par hasard, y en a t il sur la gestion des droits que propose Elois ? J’ai déjà dit à Elois que j’étais surpris de voir apparaitre ces rôles. Je penses en effet que certains rôles, comme celui de production du DU, devrait être protégé et pas trop “générique” afin d’empêcher (par conception) tout dérive possible de ce droit fondamentale. Aussi pour les algo restent simple (KISS comme dit elois )
Dis autrement, je ne penses qu’il faille trop anticiper les besoins futurs (comme les droits forgerons, droits de vote) avant la migration. Il est tout a fait possible d’avoir une gestion des droits génériques, en dehors du droit membre. Ainsi, on ne pourra pas retirer ou ajouter ce droit autrement que via les extrinsics relatifs de la toile de confiance.
C’est philosophique, mais ca me parait important pour éviter les dérives…

Je ne résiste pas à placer cette référence autrement littéraire :

“Cédric, Cééédric, reviens !”
“Bah pourquoi ?”
“Parceque la France, elle a besoin de toiiii !”

[cgeek]

@cgeek

Ce sera sans moi

Bon, il s’est passé quelques mois et j’ai eu le temps de décolérer.

Je vais essayer de suivre le mouvement impulsé par Eloïs qui semble prendre, avec mes humbles moyens actuels.

Je ne sais pas trop s’il y a des besoins, mais ce qui m’intéresse le plus en ce moment ce sont les tests automatisés. @elois y a-t-il une partie du code que tu aimerais voir renforcée à ce niveau ?

[tuxmain]

Il manque des tests sur la wot, quelques tests unitaires je pense mais surtout des tests couvrant toutes les fonctionnalités de la wot en même temps :

Add more wot integrations tests (#28) · Issues · nodes / rust / Duniter v2S

[elois]

@cgeek

Je ne sais pas trop s’il y a des besoins, mais ce qui m’intéresse le plus en ce moment ce sont les tests automatisés. @elois y a-t-il une partie du code que tu aimerais voir renforcée à ce niveau ?

Oui il y a des besoins niveau test, j’avais justement fait exprès de passer du temps à créer l’architecture technique pour les tests mais en écrivant peu de tests pour laisser de la place aux autres contributeurs là-dessus

Il y a 4 niveaux de tests automatisés:

1. Les tests unitaires: dans le code source lui-même au plus proche des fonctions testées: généralement écrit par le développeur qui à écrit le code concerné, donc je n’attends pas d’aide là-dessus, sauf pour ceux qui contribuent au code de prod (tuxmain est le seul à avoir franchi le cap pour le moment).
2. Les tests d’intégration au niveau d’une pallet: créer un faux runtime intégrant juste cette pallet et les autres pallet nécessaire. Exemple: pallets/certification/src/tests.rs · master · nodes / rust / Duniter v2S · GitLab
3. Les tests d’intégration au niveau d’un runtime: comme 2. mais avec le vrai runtime. Déjà plus complexe a setup mais plus complet. Exemple: runtime/gdev/tests/integration_tests.rs · master · nodes / rust / Duniter v2S · GitLab
4. Les tests end2end: là on spawn carrément un nœud qui init une blockchain et on interagit avec lui via RPC uniquement. C’est probablement les tests les plus simples à appréhender pour qui ne connais pas la codebase, j’ai écrit un README dédié pour ces tests: end2end-tests/README.md · master · nodes / rust / Duniter v2S · GitLab

Je pense que tu peux contribuer aux tests niveau 3 et 4

Tu risques quand même de bien galérer au début, le plus simple c’est qu’on se cale une visio (après que tu es regardé la doc), pour t’aider à te lancer

[cgeek]

Merci, je pense que je vais graduellement passer des tests sur sur les étapes 1 à 4, et si je galère vraiment, je solliciterai votre aide.