me parait impossible, dans un temps raisonnable. je vois 2 raisons:
l’expressivité d’un language est infini (les librairies sous jacente, peuvent avoir des problemes)
les facteurs externe ne sont pas prévisible
on peut parler de maximiser la couverture et meme dans ce cas, je ne suis pas sur que les tests soient complets. par exemple si je test une addition peux-tu me dire avec certitude le nombre de cas qu’il faut tester ?
La couverture de tests mesure la quantité de code executé lors des test unitaires, pas les millions d’inputs possible à tester. c’est ce que je qualifierais de borne inférieur. pas de borne supérieur. la borne supérieur n’est pas facilement mesurable (voir pas du tout).
c’est pourquoi quand on programme le pilote automatique d’un avion, ce sont generalement des personnes differentes qui s’occupe de tester, pour éviter le biais evident du développeur qui à écrit la fonction.
je fais le chieur mais je n’ai pas, moi même, écris beaucoup de tests unitaires donc prenez pas ca de travers. c’est juste une suggestion pour les motivés avec un esprit rigoureux.
La rédaction de tests n’est pas réservée aux développeurs. Mais cela ne les empêche pas d’en écrire non plus, les visions ne sont pas les mêmes et un développeur imaginera des cas que l’utilisateur ne pourra jamais imaginer pour la simple raison qu’il ignore les détails d’implémentation. Inversement, un utilisateur pourra imaginer des cas auxquels n’aurait pas pensé le développeur.
D’ailleurs si aujourd’hui Duniter tourne encore, c’est bien grâce aux tests que des développeurs ont rédigé. Donc, oui, ce sont bien des tests.
Cela dépend de la définition de “tout tester”. Si cela signifie « toute ligne de code doit avoir été exécutée par un test », ou encore « tous les cas de ce cahier de test doivent être passés avec succès », alors c’est possible.
Mais si c’est « couvrir tous les cas imaginables par un humain », alors effectivement c’est impossible en l’état des connaissances de l’humanité. Rien que pour les inputs de clés asymétriques possibles, il y en a bien de trop.
je parlais pas d’utilisateurs, juste de testeurs. je faisais une opposition entre testeurs et developeurs
“code coverage” par definitions c’est 100% quand chaque ligne de code est executé au moins une fois, pour le coup, c’est pas ma definition c’est la definition admise par wikipedia et si on fouille les outils qui s’en charge alors tu y trouvera sans doute la meme chose.
j’ai, par le passé, travaillé dans un environnement ou les programmes sensible se testaient uniquement de cette manière, pour forcer au moins deux observateur à executer leur observation. puis il y avait les tests de non regression, puis la recette, … de nombreux outils d’integrations industriel integrent cela dans leur process.
le coeur du sujet, c’est de dire “le developpeur est sans doute le pire testeur de son code”, encore une fois c’est très bien de le faire. c’est mieux que de ne pas le faire (ma methode :p) et ca peux aider le developpement mais on fabrique pas un avion ou une centrale nucleaire de cette facon pour la raison ci-dessus!
j’en conclus une seule chose:
c’est un bon exercice lorsque des gens s’interessent, de suggérer d’écrire des tests.
Les tests boite blanche, dont la rédaction nécessiter de connaître comment fonctionne le dev derrière -> ne peut être fait que par un développeur
Les tests boite noire -> tests agnostiques de la façon dont fonctionne le dev derrière, tests donc purement fonctionnels. Peuvent être écris par des personnes qui n’ont pas développés la partie testée.
NB: rien a voir avec le découpage tests unitaires/tests d’intégration qui est une autre façon de découper les tests.
En effet je pense qu’avoir des tests boite noire écris par des gens qui n’ont pas développeur les serveurs blockchain serait très intéressant et nous ferai gagner en fiabilité
Après faut il encore qu’il y ai des volontaires pour les concevoir puis les implémenter.
C’est pas mal, mais les tests boîte noire ne sont pas sans intérêt même s’ils sont écrits par des devs. C’est juste que tu testes la fonction offerte par l’interface “boite noire”.
La plupart des tests automatisés actuels de Duniter sont de type boite noire.
J’aurais peut-être préféré que cette documentation reste encore dans le dépôt Duniter, car c’est actuellement la seule implémentation de DUNP et DUBP qui fait tourner la Ğ1.
Mais bon, faut bien à un moment se détacher et laisser les autres implémentations prendre la relève. Centraliser les RFC est aussi une bonne chose.
Faudra modifier deux dépôts pour une future évolution protocolaire et de l’implémentation de Duniter, mais comme peu d’entre elles sont prévus. Ça va.
