Have a testing strategy

Imagine a testing plan to ensure the covering of:

• code (with coverage %)
• features

changed milestone to %runtime-701

added C-doc C-integrationtests D-medium ET-weeks P5-sometimesoon RN-silent S-ToDo T-security labels

assigned to @c-geek

changed milestone to %runtime-800

marked this issue as related to #155 (closed)

mentioned in merge request !215 (merged)

changed milestone to %runtime-801

mentioned in issue #28 (closed)

changed milestone to %runtime-802

unassigned @c-geek

changed milestone to %runtime-803

removed RN-silent label

removed milestone %runtime-803

https://blog.rng0.io/how-to-do-code-coverage-in-rust/#running-locally

grcov a l'air de faire le job (coverage), mais pour l'instant je maitrise trop mal l'écosystème rust pour l'intégrer (la compilation globale de duniter-v2s échoue chez moi)

la compilation globale de duniter-v2s échoue chez moi

Problème d'espace disque ? Sinon ce serait intéressant de faire un ticket pour montrer le message d'erreur pour voir si on a quelque chose à ajouter.

Ok pour grcov, ce serait bien de le mettre en place en effet.

À propos des tests unitaires :

Certaines palettes ont des tests qui racontent une histoire (par exemple universal-dividend), peu nombreux mais très longs et qui testent beaucoup de comportements de manière intriquée.

J'y vois plusieurs inconvénients :

• C'est dur de savoir exactement quels sont les comportements testés. #272 (closed) montre qu'on peut facilement oublier des cas.
• Si on veut changer de comportement, il faut relire l'intégralité du test et faire des modifications ad-hoc, ce qui fait perdre son intérêt au test.

Je serais favorable à des tests plus courts mais plus nombreux, orientés chacun sur un comportement précis.

On laisse les tests fleuves aux tests d'intégration.

Pour les tests d'intégration, il serait même intéressant de coder des automates formels et de vérifier leur parité avec le comportement de Duniter avec du fuzzing (envoyer des extrinsics aléatoires et vérifier que l'automate accepte l'état). Comme stage de recherche ça pourrait être intéressant si on avait autant d'argent que Web3 :p

C'est sûrement parce qu'un test fleuve a un très bon rapport couverture/prix pour le développer. Mais c'est effectivement un gain plutôt court-termiste qui génère une dette en face (les inconvénients que tu évoques), si l'on peut c'est mieux de faire des tests isolés.

Par contre là aussi il y a un risque de dette vu que chaque test reconduit une même mécanique qu'il vaut mieux éviter de dupliquer, en apportant une factorisation.

Autre suggestion de type de test qu'on pourrait avoir : des Golden Tests (sujet évoqué ici : https://forum.duniter.org/t/can-identitie-have-no-associated-account/12824/5). On est là plutôt dans du test coûteux, donc pas joués de façon systématique.

Mais pour reformuler l'idée : on crée des fichiers qui contiennent l'attendu d'un paquet de données métier (par exemple la fiche d'un membre de la Ğ1), et on fait reproduire ce même fichier en consultant le Storage (via le Runtime ou même plus haut via l'API RPC) et on vérifie que les fichiers sont identiques.

J'appliquais déjà ce type de tests pour Duniter v1 afin de vérifier que le "Storage" (les index V1) généré pur un scénario donné était cohérent avec l'attendu.

L'avantage : l'écriture des fichiers d'attendus peuvent être réalisés par des non-développeurs, mais qui connaissent le métier (ex. : un membre importé de la V1 doit avoir comme statut "Membre" au bloc#0).