Dans le but de ne pas polluer le sujet Try/Catch, mais dans le but de mieux comprendre la discussion entre les assertions / Tests unitaires, je relance un autre fil de discussion.
Je comprends que Koala01, proposerait de remplacer des tests unitaires par des postconditions. (Je résume, je ne sais pas faire des messages aussi longs que lui !)
Pour ma part, mon domaine est le logiciel critique, où les tests unitaires doivent être couvrants (couverture structurelle, preuves de couverture ...). Donc, à la sortie des tests unitaires, je sais que la fonction/service de chaque librairie/code correspond à sa spécification/design.
Inversement, je comprends de la programmation par contrainte :
Les préconditions ("le plus souvent, on limitera les assertions aux paramètres de la fonction" dixit Koala01) : Lors des tests d'intégration, quand j'utilise un autre code, je sais rapidement que je l'utilise mal. Et là, en effet, la vérification des arguments avec des "assert" est la meilleure méthode.
Les postconditions : Si j'ai fait des TU couvrants, les postconditions ne tomberons jamais, toutes les erreurs seront vues avec les TU (de toute manière, les TU permetent de découvrir beaucoup plus de bug qu'une simple postcondition !)
Les invariants: Idem post conditions
"Cependant, si tu y réfléchis un tout petit peu, le résultat obtenu avec tes tests unitaire est -- a priori -- très proche de celui que tu obtiendrais en parsemant ton code d'assertions" dixit Koala01. Pour moi, c'est discutable: Comme dit, les tests unitaires seront plus couvrants que la simple postcondition. C'est d'autant faux si de plus on développe suivant le TDD et "l'intégration continue".
"J’ajoute que l’on peut se passer des assertions (pour les preconditions en faisant un wide contract, pour les post conditions par des tests). L’inverse n’est pas vrai." Dixit GBDivers. Ok pour la seconde partie (postconditions), mais que veux dire "Wide Contract" ? S'agit-il de la "programation défensive" (vérification explicite de tous les arguments, réf Cyber sécu) ?
Est ce que je n'ai pas compris les subtililés des messages ?
Je profite de ce message pour vous souhaiter mes meilleurs voeux pour 2023.
"J’ajoute que l’on peut se passer des assertions (pour les preconditions en faisant un wide contract, pour les post conditions par des tests). L’inverse n’est pas vrai." Dixit GBDivers. Ok pour la seconde partie (postconditions), mais que veux dire "Wide Contract" ? S'agit-il de la "programation défensive" (vérification explicite de tous les arguments, réf Cyber sécu) ?
Pour simplifier :
- contrat : la fonction fait ce qu’elle est censee faire quand le contrat est respecte. Hors contrat, le comportement de la fonction n’est pas defini.
- programmation defensive : on s’attend a ce que l’utilisateur fait de la merde
- wide contract : le contrat est le plus large possible, c’est a dire que toutes les valeurs donnent un comportement defini (qui peut etre une erreur, une exception, etc)
Si on prend l’exemple de vector. at() va verifier pour chaque appel que l’index est valide, ce qui est inutile si tu as un code qui garantie la validite de l’index. C’est des verifications inutiles “au cas ou”, c’est de la programmation defensive et un wide contract en debug et release.
[] en debug va (dans les implementations recentes uniquement je crois) faire un assert sur l’index. Ce qui veut dire en quelque sorte que [] a un comportement definie EN DEBUG pour n’importe quelle valeur d’index (wide contract). Au contraire, en release, il n’y a pas d’assert, donc le comportement est indefini si l’index est invalide. On est hors contrat (Et donc la suite de l’execution peut donner n’importe quoi).
Mon propos etait surtout de souligner que dans un cas limite (wide contract), on pouvait ne plus avoir de precondition et rendre les asserts inutiles. Alors que les tests resteraient utilent. C’est vraiement une question de design d’API publique.
Pour le reste, je suis d’accord avec toi sur la couverture.
Merci GBDivers, pour cette réponse. Moi aussi, je suis d'accord. (Je venais de trouver ce qu'est le "wide contract".)
Juste une remarque : la programmation défensive est arrivée chez nous avec la cybersécurité.
"- programmation défensive : on s’attend a ce que l’utilisateur fait de la merde" dixit GBDivers.
Non, l'utilisateur ne fait pas de la merde, mais quelqu'un cherche à prendre le contrôle au travers de lacune du code. Si ce n'était que le développeur, utilisateur de ma lib, ce ne serait pas grave ! On saurait faire (avec un bon contrat de travail, et des clauses "qui vont bien !") Mais si la menasse est extérieure…
De ce que je comprend, on n’a pas exactement la meme definition pour la programmation defensive. A ma connaissance, de base, c’est pas un concept de cyber secu. https://en.wikipedia.org/wiki/Defensive_programming. Mais cela peut effectivement etre utilise aussi en cyber secu, puisque les comportements non definis peuvent servir d’exploit pour des hacks.
C’est un tres bon point, auquel je n’avais pas forcement pensé.
Je comprends que Koala01, proposerait de remplacer des tests unitaires par des postconditions. (Je résume, je ne sais pas faire des messages aussi longs que lui !)
Salut,
Attention, je ne propose pas de faire des assertions à la place de tests. Je dis juste que, d'un point de vue purement conceptuel, cela pourrait être une solution envisageable, sans prétendre ni que la solution envisagée soit pratique, et encore moins qu'elle soit "meilleure qu'une autre" (quel que soit le sens que l'on peut donner à "meilleure").
Tout ce que je dis, c'est que, la programmation par contrat impose des obligations aux deux parties prenantes (l'appelant et l'appelé):
l'appelant doit fournir des données valides et
l'appelé doit fournir un résultat correct à partir du moment où il a recu des données valides.
En cela, il serait donc "logique" (bien que pas forcément pratique à mettre en oeuvre) de s'assurer que le résultat obtenu lors de l'appel une fonction soit "correct et cohérent".
Il se fait que, lorsqu'ils sont bien utilisés, les tests unitaires permettent (en théorie) d'apporter cette garantie de résultat correct et cohérent.
Je ne discute absolument pas de cela, et je ne proposerai jamais "sérieusement" de remplacer les tests unitaires par des assertions dans son propre code (comprend: au point d'inciter les gens à le faire)
Dedeun a écrit:
Pour ma part, mon domaine est le logiciel critique, où les tests unitaires doivent être couvrants (couverture structurelle, preuves de couverture ...). Donc, à la sortie des tests unitaires, je sais que la fonction/service de chaque librairie/code correspond à sa spécification/design.
Oui, les tests unitaires sont là (lorsqu'ils sont correctement utilisés du moins) pour apporter ce genre de garantie, et il n'y a pas de raison que cela change
Le problème des tests unitaires, c'est qu'il n'apporte aucune garantie quant à la validité des données entrantes. Et c'est ce qui nous amène au point suivant que tu abordes:
Dedeun a écrit:
Les préconditions ("le plus souvent, on limitera les assertions aux paramètres de la fonction" dixit Koala01) : Lors des tests d'intégration, quand j'utilise un autre code, je sais rapidement que je l'utilise mal. Et là, en effet, la vérification des arguments avec des "assert" est la meilleure méthode.
Les postconditions : Si j'ai fait des TU couvrants, les postconditions ne tomberons jamais, toutes les erreurs seront vues avec les TU (de toute manière, les TU permetent de découvrir beaucoup plus de bug qu'une simple postcondition !)
Les invariants: Idem post conditions
Exactement... C'est ce que les gens ont peut-être du mal à comprendre...: lorsque tu place une assertion sur une précondition dans le cadre de la programmation par contrat, tu garanti le respect de ta contrainte dés que t'écartes un temps soit peu du développement de ta fonctionnalité / de ton service.
Et, par la même, tu ne peux que contribuer à améliorer la qualité du produit final en ajoutant des assertions sur les préconditions.
Je pourrais juste discuter "un tout petit peu" en ce qui concerne les invariants, car il y en a ** parfois ** qui méritent également d'être considérés ** sous certaines conditions ** comme des préconditions.
En cela, il se peut qu'un invariant soit vérifié au niveau des tests unitaires, comme toute précondition qui se respecte, mais il se peut ** aussi ** qu'il soit intéressant d'en garantir le respect en tant que pré condition sous la forme d'une assertion
Dedeun a écrit:
"Cependant, si tu y réfléchis un tout petit peu, le résultat obtenu avec tes tests unitaire est -- a priori -- très proche de celui que tu obtiendrais en parsemant ton code d'assertions" dixit Koala01. Pour moi, c'est discutable: Comme dit, les tests unitaires seront plus couvrants que la simple postcondition. C'est d'autant faux si de plus on développe suivant le TDD et "l'intégration continue".
A condition, encore une fois, que les TDD soient utilisés correctement. C'est à dire (en simplifiant pour ne pas réécrire un cours sur le sujet ici)
Que les tests soient écrits avant le code et en "dirigent" l'évolution et non l'inverse
Que les tests unitaires soient fait de manière incrémentielle pour pouvoir diriger l'évolution du code
que tout test "correct" à un moment soit maintenu aussi longtemps que la fonctionnalité développées
que toute modification du code n'ait pour but que de faire passer "un nouveau test" sans casser les tests existants.
A ce moment là, nous sommes tout à fait d'accord sur l'immense intérêt des tests unitaires.
Le problème étant que nous avons tous pu croiser des projets dans lesquels les principes de base du TDD n'étaient pas respectés, avec une qualité de développement exécrable malgré une mesure de couverture plus que raisonnable, simplement parce que des "petits malins" se sont amusés à ajouter un nombre (parfois honteux) de lignes inutiles dans leur code juste pour atteindre le quota de couverture requis.
Lorsque je vois ce genre de pratiques, j'en viendrais presque à préférer que le développeur d'une fonction racine_carree prenne la peine de placer une assertion sur le résultat -- et ce d'autant plus qu'une seule pourrait suffire et qu'elle est simple à exprimer -- plutôt que de voir un "petit malin" ajouter cinq lignes inutiles à la fonction juste pour améliorer le taux de couverture
Mais, encore une fois, je ne prétend absolument pas que ce soit une solution efficace, ni même pratique. Et je ne prétend absolument pas non plus qu'elle pourrait être envisagée partout.
Je dis juste que ce serait sans doute un moindre mal parce que le problème de fond est beaucoup plus grave qu'il n'y parait et dont l'explication sort du cadre de ce débat
Mais mettons nous bien d'accord : Je n'essaye pas de nier que je suis un farouche partisan de la programmation par contrat et je reconnais les limites du TDD et de l'intégration continue.
Cela ne signifie absolument pas que je sois contre la programmation par contrainte, et encore moins que je sois contre le principe du TDD ou de l'intégration continue.
Bien au contraire: j'estime que programmation par contrat, programmation par contrainte et TDD s'emboitent tellement bien entre eux en gommant les différents inconvénients relatifs à chaque concept qu'il est presque "suicidaire" d'essayer de ne pas les utiliser ensembles, comme par exemple d'imposer des contraintes sans avoir mis les contrats adéquats en place ou de n'avoir pas recours à une utilisation correcte du TDD et de l'intégration continue.
Pour résumer, le gros problème du TDD et de l'intégration continue (comme de toute méthode visant à améliorer la qualité du développement, d'ailleurs) n'est pas le TDD ou l'intégration continue, mais la manière dont la méthode sera utilisée par les développeur.
En gros, le principale problème du développement en général, juste après le client qui ne nous explique pas bien ce qu'il veut, c'est le développeur
- Edité par koala01 1 janvier 2023 à 15:58:02
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
...Le problème des tests unitaires, c'est qu'ils n'apportent aucune garantie quant à la validité des données entrantes. ...
En effet, ce n'est pas un TU sur un code/une lib qui prouve que l'utilisateur de cette procédure/lib ne fait pas d'erreur lorsqu'il l'appel. Ce n'est pas l'objectif : Tes TU valident ton développement, pas celui des autres ! Pour moi, les tests de vérification d'appels, là, on est dans des tests d'intégrations.
koala01 a écrit:
... Je dis juste que, d'un point de vue purement conceptuel, cela pourrait être une solution envisageable, sans prétendre ni que la solution envisagée soit pratique, et encore moins qu'elle soit "meilleure qu'une autre" (quel que soit le sens que l'on peut donner à "meilleure")...
Je ne vais pas être d'accord avec toi ! Pour moi, ce n'est pas une solution acceptable, car dans ce cas, ça voudrait dire que l'on fait le travail à l'enver ! Si c'est une postcondition qui tombe quand quelqu'un utilise ta lib/procédure, ça voudrait dire que c'est l'utilisateur de cette lib/prodédure qui découvre/débug ton développement ! Ça ne va pas dans le bon sens, c'est trop tard ! C'est à toi de valider ton code avant de le rendre disponible aux autres !
Je suis certainement trop pragmatique : Pour moi, la programation par contrats, ça réduit les PB d'intégration : Ca permet d'identifier "rapidement" qui est fautif : l'appelant ou l'appelé.
Et pour finir, je corrige ton dernier mot, (tu es trop gentil ! )
koala01 a écrit:
Pour résumer, le gros problème du TDD et de l'intégration continue (comme de toute méthode visant à améliorer la qualité du développement, d'ailleurs) n'est pas le TDD ou l'intégration continue, mais la manière dont la méthode sera détournée par les développeurs.
Pour moi les TU c'est un truc archaique et ce n'est pas une bonne approche. C'est comme si on voulait mesurer la longueur d'une pièce en faisant "à peu près" des pas de 1 mètre et en comptant comme ça, c'est vraiment une solution de sans domicile fixe du 18è siècle. Pour moi une meilleure solution serait d'écrire le code ainsi que les pré et post conditions et autres invariants, et laisser le compilateur vérifier mathématiquement que le code est correct. Il y a déjà des outils comme ça, comme par exemple Coq mais c'est nul ce truc c'est à nous de faire toute la preuve il y arrive pas tout seul !!
Mais de toute façon si les IA continuent comme ça elles vont finir par nous dépasser et il n'y aura plus de programmeurs donc comme ça ça règle le problème encore mieux
Non, c'est plutôt ton approche des tests unitaires (enfin, je soupçonne que ce soit celle de ton gourou) qui n'est pas la bonne.
La meilleure preuve en est que nous ne parlons pas de tests unitaires ici, mais bien de développement dirigé par les tests (Test Driven Development), ce qui est tout à fait différent, même si cela fait effectivement intervenir les tests unitaires.
Mais, avant de te descendre en flêche, et parce que ton avis m'intéresse quand même un tout petit peu, je te donne une chance d'essayer de justifier ton point de vue, car, de mon point de vue, ta comparaison est pour le moins bancale
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Pour moi une meilleure solution serait d'écrire le code ainsi que les pré et post conditions et autres invariants, et laisser le compilateur vérifier mathématiquement que le code est correct. Il y a déjà des outils comme ça, comme par exemple Coq mais c'est nul ce truc c'est à nous de faire toute la preuve il y arrive pas tout seul !!
Les contrats (pre, post, invariant) et les preuves, c‘est 2 choses differentes.
Et si tu arrives a prouver le C++, n’hesite pas a publier, certains seront heureux d’etudier ca. (Tu es en retard pour le Noel de Peuk, mais il ne t’en voudra pas si tu lui apporte ca)
Dedeun a écrit:
Je suis certainement trop pragmatique : Pour moi, la programation par contrats, ça réduit les PB d'intégration : Ca permet d'identifier "rapidement" qui est fautif : l'appelant ou l'appelé.
Et plus generalement, dans une chaine complexe d’appel de fonctions, savoir a quel moment une fonction est appelee avec des parametres invalides. (Et on peut ajouter maintenant les concepts, pour la validation des types dans une chaine complexe d’instanciation de templates)
Pour moi, contrats, TU, tests d’integration, tests blabla, preuves, tout cela repond a des problematiques differentes. C’est pas du tout interchangeable.
Bonjour à tous, Merci à nouveau pour ces réponses.
JadeSalina a écrit :
Pour moi les TU c'est un truc archaique et ce n'est pas une bonne approche. C'est comme si on voulait mesurer la longueur d'une pièce en faisant "à peu près" des pas de 1 mètre et en comptant comme ça, c'est vraiment une solution de sans domicile fixe du 18è siècle.
Oups ! Je ne sais pas ce que tu entends par TU, mais dans le logiciel critique avec preuve de couverture(*), ce n'est pas de l'approximatif. Quand on doit prouver 100% de couverture structurelle du code et de son design, on ne fait pas de l'approximatif. (Oui, j'ai bien dit "Prouver". Il ne s'agit pas uniquement de mesurer et pouvoir dire au client qu'on a atteint X% de couverture. Non, dans mon cas, il faut pouvoir le prouver à une tierce personne, sans lien avec le client, ni le fournisseur.) Utiliser un outil automatique, c'est en effet drôlement bien… si on sait prouver que cet outil n'est jamais buggé et ne retournera jamais de fausse mesure de couverture ! Il faut donc avoir la même rigueur dans le développement de l'outil que dans le soft final... avec une couverture structurelle de 100%. "De l'œuf et de la poule, quel est le premier ?"
(*) Dans mon cas: Logiciel critique, ça veut dire : un bug peut conduire à la morts de 150 personnes (Avionique).
Merci pour toutes ces précisions. Je ferme le sujet.
Dans le monde avionique, la vérification est un peu schizophrène : on sait que les tests ne prouvent rien (ça sert à trouver des bugs), pour autant ça reste la méthode la plus utilisée dans l'absolu pour justifier de la qualité globale du soft. Mais bon, ils vont progressivement vers de la preuve unitaire. Peu importe le critère de couverture (réaliste), même 100% de couverture, ça ne donne pas de garantie. Ni une preuve formelle complète d'ailleurs : qu'est ce qui garantit que la spécification est correcte ?
Pour en revenir aux assertions et aux tests, c'est juste des notions qui sont orthogonales. En particulier, les assert c'est de l'outillage au sein du code, en eux-mêmes, en l'absence d'exécutions, ils n'ont aucune capacité de détection. C'est les tests qui permettent de créer des exécutions. La présence des assert peut justement permettre de faire péter des TU et de détecter des bugs supplémentaires qui n'auraient pas forcément été vus sinon.
Je ne suis pas convaincu qu'il soit pertinent de comparer assertions et tests unitaire, car leur raison d'être est différente.
Certes, ce sont tous les 2 des outils. - L'un a pour but de mettre en place des garde-fous (ca gueule, parce que tu as fait une connerie). - L'autre a pour but d'apporter la preuve que le comportement constaté est bien celui escompté.
Non, c'est plutôt ton approche des tests unitaires (enfin, je soupçonne que ce soit celle de ton gourou) qui n'est pas la bonne.
La meilleure preuve en est que nous ne parlons pas de tests unitaires ici, mais bien de développement dirigé par les tests (Test Driven Development), ce qui est tout à fait différent, même si cela fait effectivement intervenir les tests unitaires.
Mais, avant de te descendre en flêche, et parce que ton avis m'intéresse quand même un tout petit peu, je te donne une chance d'essayer de justifier ton point de vue, car, de mon point de vue, ta comparaison est pour le moins bancale
Je pense qu'on a pas les outils nécessaires pour pouvoir prouver automatiquement qu'un code est bon par rapport à ce qu'il est censé faire et donc on se rabat sur des techniques de TU mais qui ne sont là au final que pour mettre du sparadrap sur notre incompétence. Après c'est certainement une bonne idée d'en faire en pratique car on n'a pas forcément mieux à l'heure actuelle mais la vraie bonne chose à faire pour l'avenir de l'humanité c'est développer des outils capables de montrer par A + B que le code est correct, et pas juste se contenter de "ça a l'air de marcher sur ces jeux de test". Après je sais même pas si c'est possible, il y a le théorème de Rice qui dit que c'est "indécidable" mais je n'y crois pas, je pense que c'est lui qui a pas compris et que quelqu'un va trouver le moyen de le faire
gbdivers a écrit:
Et si tu arrives a prouver le C++, n’hesite pas a publier, certains seront heureux d’etudier ca. (Tu es en retard pour le Noel de Peuk, mais il ne t’en voudra pas si tu lui apporte ca)
Pour le C++ (ou même le C btw) ça va être compliqué à cause des undefined behavior. Si on a pas une vraie spécification du langage qui dit ce qui se passe, c'est un peu la galère je pense. Comme dit Casey, "if you have a spec that has undefined behavior in it, then you don't have a spec" (https://guide.handmadehero.org/code/day578/#9481)
Dedeun a écrit:
Utiliser un outil automatique, c'est en effet drôlement bien… si on sait prouver que cet outil n'est jamais buggé et ne retournera jamais de fausse mesure de couverture ! Il faut donc avoir la même rigueur dans le développement de l'outil que dans le soft final... avec une couverture structurelle de 100%. "De l'œuf et de la poule, quel est le premier ?"
Oui aha c'est rigolo ce problème de la poule et de l'oeuf, mais peut être qu'on peut produire l'outil d'une manière "plus ou moins prouvée", pour ensuite pouvoir utiliser ce même outil pour faire la version suivante prouvée, un peu comme les compilateurs écris dans le langage du compilateur, le tout premier il faut le créer d'une autre manière mais une fois qu'on l'a on peut le réécrire dans le langage lui même c'est rigolo ça.
Quand vous dites "100% de couverture structurelle" ça veut dire que 100% de coverage ? Je sais pas si c'est une mesure fiable, il y a une conférence qui explique que même avec 100% de coverage on peut laisser passer des bugs et que ça vaut pas grand chose au final (https://youtu.be/jxBmKvS7lAo?t=6139) (je met le lien à titre indicatif, ça ne veut pas dire qu'il faut écouter tout ce qu'il dit, quand il parle de se passer du débugueur grâce au TDD, c'est des foutaises, je pense qu'il n'a pas assez d'expérience)
Dedeun a écrit:
(*) Dans mon cas: Logiciel critique, ça veut dire : un bug peut conduire à la morts de 150 personnes (Avionique).
Dieu me bénisse que je n'ai pas à faire ça j'aurais trop peur, je préfère faire des petits programmes pour le plaisir et laisser les choses critiques à des pros.
il y a le théorème de Rice qui dit que c'est "indécidable" mais je n'y crois pas, je pense que c'est lui qui a pas compris et que quelqu'un va trouver le moyen de le faire.
Si le théorème de Rice est faux, la preuve d'indécidabilité du problème de l'arrêt aussi. Donc c'est pas juste Rice qui se gourre, c'est aussi Church, Turing, Rózsa, et tous ceux qui sont passés après eux. Et vu la simplicité des preuves qu'ils ont réussi à sortir, ça semble assez compromis qu'ils se soient gourrés.
JadeSalina a écrit:
gbdivers a écrit:
Et si tu arrives a prouver le C++, n’hesite pas a publier, certains seront heureux d’etudier ca. (Tu es en retard pour le Noel de Peuk, mais il ne t’en voudra pas si tu lui apporte ca)
Pour le C++ (ou même le C btw) ça va être compliqué à cause des undefined behavior. Si on a pas une vraie spécification du langage qui dit ce qui se passe, c'est un peu la galère je pense. Comme dit Casey, "if you have a spec that has undefined behavior in it, then you don't have a spec" (https://guide.handmadehero.org/code/day578/#9481)
Les undefined behavior ne sont pas un problème, on doit démontrer leur absence, et pour ça on peut produire des conditions de vérification pour toute opération pouvant amener à un undefined behavior. Et parler d'undefined behavior pour une spec, ça n'a franchement pas de sens. A la rigueur, on peut parler d'incomplétude pour une spec, ou de valeur non définie, mais ça n'a pas grand chose à voir avec la notion d'undefined behavior ...
JadeSalina a écrit:
Dedeun a écrit:
Utiliser un outil automatique, c'est en effet drôlement bien… si on sait prouver que cet outil n'est jamais buggé et ne retournera jamais de fausse mesure de couverture ! Il faut donc avoir la même rigueur dans le développement de l'outil que dans le soft final... avec une couverture structurelle de 100%. "De l'œuf et de la poule, quel est le premier ?"
Oui aha c'est rigolo ce problème de la poule et de l'oeuf, mais peut être qu'on peut produire l'outil d'une manière "plus ou moins prouvée", pour ensuite pouvoir utiliser ce même outil pour faire la version suivante prouvée, un peu comme les compilateurs écris dans le langage du compilateur, le tout premier il faut le créer d'une autre manière mais une fois qu'on l'a on peut le réécrire dans le langage lui même c'est rigolo ça.
Ça ne change rien au fait que :
il y a forcément une base à laquelle on est forcé de faire confiance (théorème d'incomplétude de Gödel, tout ça),
la spécification de l'outil peut être imprécise, incomplète, fausse par rapport à "ce qu'on voulait vraiment".
JadeSalina a écrit:
Quand vous dites "100% de couverture structurelle" ça veut dire que 100% de coverage ? Je sais pas si c'est une mesure fiable, il y a une conférence qui explique que même avec 100% de coverage on peut laisser passer des bugs et que ça vaut pas grand chose au final
Des critères de couverture, il y en a des camions. Dans l'avionique, le critère utilisé c'est le critère MC/DC. Et ça vaut ... ce que ça vaut. L'avantage est qu'elle garantit qu'un grand nombre de tests ont été réalisés afin de trouver des bugs dans le code et que tous les problèmes révélés par ces tests ont été corrigés. Le rationale c'est :
empiriquement, un code produit dans un contexte industriel contient environ 25 bugs par kLOC avant vérification,
par la production des tests, on va détecter un maximum de bugs parmi ceux-ci avec une certaine distribution aux niveaux unitaire et intégration,
on veut un pourcentage notable des bugs présumés détectés + suffisamment de temps passé à ajouter des tests + suffisamment de temps sans détecter de nouveau bug,
une fois ce point atteint, on justifie de la qualité de la suite de tests qu'on a produit.
En TL;DR: en simplifiant, le truc le plus adapté à la vérification des post-conditions, ce sont les tests unitaires -- je le reprends de J. Lakos, qui le reprennait lui même de quelqu'un d'autre si mes souvenirs sont bons.
Mais comme dit par mes VDD, c'est grâce aux tests que l'on "vérifie" : que l'on appelle toujours en respectant les pré-conditions, et que les résultats obtenus sont bien conformes à ce qui est attendu (-> post-conditions)
Car tester le résultat d'un cosinus coûtera aussi cher que la fonction (c'est pas "entre -1 et +1", mais "valeur de l’abscisse du point P sur le cercle unitaire tel que l'angle Ox ^ OP vaut le paramètre du cosinus"). Pareil pour pour une postcondition sur `sort` (il faut que l'on retrouve exactement les mêmes éléments qu'en paramètre et en même nombre...). Etc, etc.
Et la postcondition, c'est l'état attendu du système complet
Après les TU "font" plus de choses: comme permettre d'explorer plus de combinatoires "état de départ" -> "postcondition associée", et aussi donc sur la couverture.
Je pense qu'on a pas les outils nécessaires pour pouvoir prouver automatiquement qu'un code est bon par rapport à ce qu'il est censé faire et donc on se rabat sur des techniques de TU mais qui ne sont là au final que pour mettre du sparadrap sur notre incompétence. Après c'est certainement une bonne idée d'en faire en pratique car on n'a pas forcément mieux à l'heure actuelle mais la vraie bonne chose à faire pour l'avenir de l'humanité c'est développer des outils capables de montrer par A + B que le code est correct, et pas juste se contenter de "ça a l'air de marcher sur ces jeux de test". Après je sais même pas si c'est possible, il y a le théorème de Rice qui dit que c'est "indécidable" mais je n'y crois pas, je pense que c'est lui qui a pas compris et que quelqu'un va trouver le moyen de le faire
Les autres ont répondu aux autres "arguments". Sur cet argument, c'est le niveau 0 d'une discussion. Dire "entre les choix A, B et C, il faut choisir le choix parfait X qui n'existe pas et n'est peut etre pas possible", c'est du vide argumentatif.
Pouvez-vous prouver que vous avez trouvé le dernier bug de votre programme? Vous avez écrit une IA soi-disant parfaite qui vérifie tout pour vous. Pouvez-vous prouver qu'elle est "parfaite"? 1/2 + 1/4 + 1/8 + ... 1/2^n + ... ça ne donnera jamais 1 ...
- Edité par PierrotLeFou 3 janvier 2023 à 5:20:38
Le Tout est souvent plus grand que la somme de ses parties.
Pouvez-vous prouver que vous avez trouvé le dernier bug de votre programme?
Le point n'est même pas là. L'absence de bugs par rapport à une spécification, on sait faire (même si on peut débattre en long en large et en travers du fait que le logiciel qui vérifie peut avoir des bugs, mais bon spoiler : les outils de test aussi, les compilateurs aussi, les langages aussi, les processeurs aussi). Le point c'est que la spécification peut être fausse et ça, on n'a rien pour travailler dessus parce que c'est vraiment au niveau conceptuel.
Et il faut être prudent avec ces réflexions parce que ce sont aussi celles qu'utilisent les gens de mauvaise foi pour justifier de ne pas mettre plus de moyens dans la vérification de leurs systèmes.
Je ne dis pas qu'il ne faut pas faire de tests. On doit en faire de toutes les façons qui sont à notre disposition. Mais, effectivement, si les spécifications de départ ne sont pas claires ou cohérentes, on a un problème à la base. Et aucun test n'en viendra vraiment à bout.
Le Tout est souvent plus grand que la somme de ses parties.
- contrat : la fonction fait ce qu’elle est censee faire quand le contrat est respecte. Hors contrat, le comportement de la fonction n’est pas defini.
- programmation defensive : on s’attend a ce que l’utilisateur fait de la merde
- wide contract : le contrat est le plus large possible, c’est a dire que toutes les valeurs donnent un comportement defini (qui peut etre une erreur, une exception, etc)
Salut !
J'arrive un peu tard sur le sujet, pas trop de temps en ce début d'année !
j'aime bien tes définitions de types de fonctions, et ça me parle d'autant plus qu'à ma boîte nous vendons - entre autres - des bibliothèques, donc nos clients des programmeurs, qui peuvent potentiellement faire n'importe quoi.
C'est pour cela que les fonctions données au client sont blindées : elles testent tout, et essaient de renvoyer des messages d'erreurs propres à l'utilisateur dans tous les cas.
Par contre, en interne, les fonctions que je n'appelle que moi ou les collègues, je me permets de nous balancer un joli assert à la figure en cas de mauvaise utilisation. (d'ailleurs je travaille beaucoup aux assert mais activés sous un define particulier, pour que le client ne le voit jamais), ces assert m'avertissent quand il y a un paramètre qui ne va pas, un cas non géré, un truc jamais vu, etc....
J'ai aussi rajouté des tas et des tas de garde fous : des fonctions qui vérifient des trucs dans tous les sens sous certains define, qui me mettent le doigt bien vite sur le truc qui ne va pas, le but étant de ne pas perdre de temps à trouver pourquoi ça ne marche pas, pour corriger les soucis efficacement.
Qu'est ce que vous voudriez voir dans un bon cours sur le test d'application ?
Je ne sais pas si tu voulais te concentrer principalement sur le test du code, mais en intro, j'aimerais bien voir une vue d'ensemble de la problématique des tests : quel est le but de la qualité logiciel (avoir un produit qui répond a ce que le client attend, comment les tests les tests peuvent aider a faire cela) et les tests d'un point de vue global (allant aussi bien du test du code que des tests d’intégration que tous les éléments fonctionnent correctement ensemble, les tests de déploiement/installation/désinstallation, le test des UI et l'UX design, les tests de sécurité pour savoir s'il n'y a pas de hacks possibles, les tests en environnement critiques comme l'avion, le test du couple software/hardware, tester les outils de production comme jenkins, tester les performances, etc).
Sauf forcement entrer dans le détail mais juste pour le lecture sache que la qualité logicielle est un domaine très large et complexe, qui fait intervenir de nombreuses spécialités.
Plus spécifiquement pour les tests de code :
- les différents types de tests (unit, fonctionnelle, intégration, etc) et les limites d'une telle classification
- les notions de couverture et outils (gcov)
- comment les tests peuvent s’intégrer dans l'ensemble du processus du développement et pas comme une étape optionnelle séparée (TDD et CI/CD)
- les outils de tests (gtest, boost.test, etc), d’exécution automatique et de report des tests (CI)
- quelles valeurs tester ? Fuzzing
- qu'est-ce qui fait la qualité d'un test ? D'une couverture de tests ? (critères pour savoir quand on a assez de tests et savoir quels tests ajouter)
- tests dans le cas de multithreads. Dans le cas de calcul distribuée. Tests avec des "boites noirs" externes (libs, serveurs, etc)
Oui, j'ai toute une partie d'intro sur les généralités à propos de la V&V, des coûts des bugs et des différents niveaux auxquels on se place pour du test. Avec le temps que j'ai, je ne peux pas trop me permettre de leur faire pratiquer le TDD et la CI/CD, même si j'ai prévu de leur en parler un peu. J'ai aussi volontairement exclut les tests de performances du scope de ce qui est manipulé par les étudiants.
gbdivers a écrit:
- (1) les différents types de tests (unit, fonctionnelle, intégration, etc) et les limites d'une telle classification
- (2) les notions de couverture et outils (gcov)
- (3) comment les tests peuvent s’intégrer dans l'ensemble du processus du développement et pas comme une étape optionnelle séparée (TDD et CI/CD)
- (4) les outils de tests (gtest, boost.test, etc), d’exécution automatique et de report des tests (CI)
- (5) quelles valeurs tester ? Fuzzing
- (6) qu'est-ce qui fait la qualité d'un test ? D'une couverture de tests ? (critères pour savoir quand on a assez de tests et savoir quels tests ajouter)
- (7) tests dans le cas de multithreads. Dans le cas de calcul distribuée. Tests avec des "boites noirs" externes (libs, serveurs, etc)
(1) Tu penses à quoi en particulier ? (outre le fait que les limites entres les classes peuvent être floues)
(2) Présenté et pratiqué mais avec la limitation inhérente aux outils mainstream qui ne gère que des couvertures un peu nazes
(3) Présenté mais non pratiqué
(4) J'en ai trouvé un qui semble assez simple à prendre en main pour les faire manipuler, il faut que j'essaie un peu plus longuement
(5) J'ai prévu de faire un point dessus, mais je n'ai pas le temps de préparer une vraie section dessus cette année
(6) Ça va un peu avec (2), j'ai aussi des slides sur des métriques empiriques et l'état d'esprit d'un testeur
(7) Ouais alors là pour le coup, je n'ai pas suffisamment manipuler ça pour l'ajouter. Il faudrait que je regarde ce qui existe mais de loin ça m'avait toujours semblé un peu pas ouf.
Juste connaitre le vocabulaire. Test unitaire, test d’intégration, etc. En gros, savoir a quoi correspond ces termes : https://en.wikipedia.org/wiki/Software_testing#Testing_types,_techniques_and_tactics
Ah ok. Ce que tu as dit : "(outre le fait que les limites entres les classes peuvent être floues)"
EDIT
Ca me fait penser, on a eu des discussions au boulot a propos d'un executive order to improve cybersecurity, il y a des recommandations officielles pour la vérification du dev logiciel, ça peut te donner des éléments d’idée (et montrer que c'est des choses concrètes dans l'industrie, voire engager la responsabilité pénale ou civile des entreprises et devs) : https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8397.pdf. Il y a une partie sur les tests et les critères de couverture. Il y a peut être des choses équivalentes en France.
... Qu'est ce que vous voudriez voir dans un bon cours sur le test d'application ? ..
Oui.
Ksass`Peuk a écrit :
... Est ce que vous avez déjà rencontré des critères de couvertures autres que "couverture des instructions" et "couverture des conditions" ? ...
Non [incluant bien sûr la "Modified Condition Decision Coverage" (MCDC)]
Ksass`Peuk a écrit :
...(Et d'ailleurs, est-ce que vous connaissez les nombreux autres critères qui existent ?)
Non.
gbdivers a écrit :
- (1) les différents types de tests (unit, fonctionnelle, intégration, etc) et les limites d'une telle classification
- (2) les notions de couverture et outils (gcov)
- (3) comment les tests peuvent s’intégrer dans l'ensemble du processus du développement et pas comme une étape optionnelle séparée (TDD et CI/CD)
- (4) les outils de tests (gtest, boost.test, etc), d’exécution automatique et de report des tests (CI)
- (5) quelles valeurs tester ? Fuzzing
- (6) qu'est-ce qui fait la qualité d'un test ? D'une couverture de tests ? (critères pour savoir quand on a assez de tests et savoir quels tests ajouter)
- (7) tests dans le cas de multithreads. Dans le cas de calcul distribuée. Tests avec des "boites noirs" externes (libs, serveurs, etc)
(1) Je suis d'accord avec GBDivers, c'est un peu le bordel dans la tête des développeurs/responsables de projet. De plus, à mon avis, je rajouterais aussi, Les tests "boites Noires"/Test "boite Blanches", les "test de débug"/les "tests formels", les tests automatiques/tests manuels, les tests des HMI/GUI, en ce qui concerne les softs embarqués, la différence entre les "tests hors cible"/"Test sur-cible".
(2) Pour les couvertures, dans mon domaine d'activité (DO178C/ED12C), ce n'est pas réellement un pb d'outillage, mais de méthodologie / documentations : Hight level requirements / Low level requirements / traçabilités / tests procedures / tests results...
(3) Ok, mais surtout que ça peut faire gagner du temps en intégration finale / validation, si c'est fait au fil de l'eau (en temps masqué)
(4) Là, je suis incompétent, et j'ai beaucoup à apprendre !
(5) Oui, en effet, les classes des valeurs testées : valeurs valides, valeurs aux limites, valeurs hors limites... Le fuzzing, que je connais dans le domaine de la cybersécurité (critère d'arrêt, plus de 4 millions de tests, plus d'un mois de test non-stop sur PC)
(6) Je suis curieux de cette partie. Dans mon domaine d'activité, c'est contractuel et normalisé. Ailleurs, je ne sais pas ce qui se fait.
(7) Là aussi, je suis curieux...
On peut ajouter :
La documentation des tests : La différence entre le STP (software tests procedures) [Identification du test / Objectif / configuration initiale / procédure / Résultat attend] et le STR (Software tests result) [Date / Version du soft / conforme ou non / Identification de la fiche d'anomalie éventuelle]
La cybersécurité : Les PenTests, le fuzzing
L'indépendance entre le développeur et le testeur
Les liens avec la gestion de configuration : fiche d'anomalie / rejeux / identification
Comment reprendre les tests en cas de reprise / maintenance d'un soft X mois/année après. (Je n'ai pas beaucoup d'idée, mais pour moi, c'est une grosse difficulté)
Etc
Je me permets une remarque : Ne faudrait-il pas ouvrir un autre Post ? Celui-ci concerne un autre sujet. Cependant, ce nouveau sujet m'intéresse beaucoup.
Ca me fait penser, on a eu des discussions au boulot a propos d'un executive order to improve cybersecurity, il y a des recommandations officielles pour la vérification du dev logiciel, ça peut te donner des éléments d’idée (et montrer que c'est des choses concrètes dans l'industrie, voire engager la responsabilité pénale ou civile des entreprises et devs) : https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8397.pdf. Il y a une partie sur les tests et les critères de couverture. Il y a peut être des choses équivalentes en France.
Merci pour le lien. Oui l'ANSSI a des choses similaires, sur pleins d'aspects différents.
Dedeun a écrit:
(1) Je suis d'accord avec GBDivers, c'est un peu le bordel dans la tête des développeurs/responsables de projet. De plus, à mon avis, je rajouterais aussi, Les tests "boites Noires"/Test "boite Blanches", les "test de débug"/les "tests formels", les tests automatiques/tests manuels, les tests des HMI/GUI, en ce qui concerne les softs embarqués, la différence entre les "tests hors cible"/"Test sur-cible".
J'ai différencier les tests fonctionnels (boîte noire) des tests structurels (boîte blanche). J'ai croisé plusieurs fois le concept de "test formel" qui depuis le point de vue de mon domaine est une dénomination très peu informative. Je n'ai pas croisé les notions de tests hors cible et sur-cible. Si t'as des pointeurs sur ça, ça m'intéresse.
Dedeun a écrit:
(2) Pour les couvertures, dans mon domaine d'activité (DO178C/ED12C), ce n'est pas réellement un pb d'outillage, mais de méthodologie / documentations : Hight level requirements / Low level requirements / traçabilités / tests procedures / tests results...
Non parce que MC/DC est relativement facile à outiller. Ce n'est pas le cas pour beaucoup de critères de couverture plus poussés qui sont plus difficile à outiller directement.
Dedeun a écrit:
(5) Oui, en effet, les classes des valeurs testées : valeurs valides, valeurs aux limites, valeurs hors limites... Le fuzzing, que je connais dans le domaine de la cybersécurité (critère d'arrêt, plus de 4 millions de tests, plus d'un mois de test non-stop sur PC)
J'ai.
Dedeun a écrit:
(6) Je suis curieux de cette partie. Dans mon domaine d'activité, c'est contractuel et normalisé. Ailleurs, je ne sais pas ce qui se fait.
Il y a d'autres domaines pour lesquels c'est normalisé mais dans le soft plus grand public ce n'est pas le cas.
Dedeun a écrit:
(1) La documentation des tests : La différence entre le STP (software tests procedures) [Identification du test / Objectif / configuration initiale / procédure / Résultat attend] et le STR (Software tests result) [Date / Version du soft / conforme ou non / Identification de la fiche d'anomalie éventuelle]
(2) La cybersécurité : Les PenTests, le fuzzing
(3) L'indépendance entre le développeur et le testeur
(4) Les liens avec la gestion de configuration : fiche d'anomalie / rejeux / identification
(5) Comment reprendre les tests en cas de reprise / maintenance d'un soft X mois/année après. (Je n'ai pas beaucoup d'idée, mais pour moi, c'est une grosse difficulté)
Etc
Je me permets une remarque : Ne faudrait-il pas ouvrir un autre Post ? Celui-ci concerne un autre sujet. Cependant, ce nouveau sujet m'intéresse beaucoup.
Bien cordialement
(1) Probablement trop spécifique pour le public ciblé,
(2) Le fuzzing oui, le pentesting, je ne pense pas pouvoir produire un truc satisfaisant sans avoir trop d'impact sur la partie méthodes formelles du cours,
(3) Je le mentionne, mais ce n'est pas une obligation partout,
(4) Idem, c'est très spécifique aux secteurs critiques,
... J'ai différencié les tests fonctionnels (boîte noire) des tests structurels (boîte blanche)...
Aurais-tu déjà écrit quelque chose ? C'est disponible ?
Je note que pour moi, Test "Boites noir/blanche" (ou grise !), Tests Fonctionnel et Critères d'arrêts avec une couverture structurelle, c'est 3 dimensions différentes. Je suis curieux de lire ce que tu penses.
Ksass`Peuk a écrit:
...Je n'ai pas croisé les notions de tests hors cible et sur-cible. Si t'as des pointeurs sur ça, ça m'intéresse.
Pour moi, les tests hors cible (Test sur un PC, avec compilation native PC, ou, croisée et utilisation sur le PC d'un émulateur de la cible), permet de valider les algorithmes complexes. Sur cible embarquée, on n'a pas toujours les mêmes possibilités de test. J'ai pas de ref sur internet, mais c'est mon expériance.
(2) Pour les couvertures, dans mon domaine d'activité (DO178C/ED12C), ce n'est pas réellement un pb d'outillage, mais de méthodologie / documentations : Hight level requirements / Low level requirements / traçabilités / tests procedures / tests results...
Non parce que MC/DC est relativement facile à outiller. Ce n'est pas le cas pour beaucoup de critères de couverture plus poussés qui sont plus difficile à outiller directement.
Mais il faut réaliser la couverture structurelle, en testant les "Low Level Requirements", et là ce n'est pas de l'outillage mais de la procédure de test.
Ksass`Peuk a écrit:
(1) Probablement trop spécifique pour le public ciblé,
Quel est le publique visé ? Et comment peut-on formaliser des tests autrement ?
Ksass`Peuk a écrit:
(3) Je le mentionne, mais ce n'est pas une obligation partout,
(4) Idem, c'est très spécifique aux secteurs critiques,
(3) En effet, ce n'est pas obligatoire, mais peut-être fournir un avantage/inconvénient : Meilleur test/couverture/compréhension du besoin versus coût/délai/lourdeur du process
(4) Je suis un peu surpris: Même dans du soft non critique, il y a besoin de savoir si un bug est corrigé ou pas, et sur quelle version (donc d'associer le résultat positif/négatif d'un test à une version).
Mais je suis d'accord avec toi, je suis peut-être un peu déformé par le boulo.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Le Tout est souvent plus grand que la somme de ses parties.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C