Cette idée revient simplement à une méthode "Self_Test" dans le contexte d'une conception à base d'objet ou orientée objet. Si vous utilisez un langage compilé basé sur des objets comme Ada, tout le code d’autotest sera marqué par le compilateur comme étant inutilisé (jamais appelé) lors de la compilation de la production, et il sera donc optimisé à l’extérieur - aucun d’entre eux n’apparaîtra dans la liste. résultat exécutable.
Utiliser une méthode "Self_Test" est une très bonne idée, et si les programmeurs étaient vraiment soucieux de la qualité, ils le feraient tous. Un problème important, cependant, est que la méthode "Self_Test" doit faire preuve d'une discipline intense, en ce sens qu'elle ne peut accéder à aucun des détails d'implémentation et qu'elle ne doit s'appuyer que sur toutes les autres méthodes publiées dans la spécification de l'objet. Évidemment, si l'autotest échoue, la mise en œuvre devra changer. L'autotest doit être un test rigoureux de toutes les propriétés publiées des méthodes de l'objet, sans jamais s'appuyer de quelque manière que ce soit sur les détails d'une implémentation spécifique.
Les langages basés sur les objets et orientés objet fournissent souvent exactement ce type de discipline en ce qui concerne les méthodes externes à l'objet testé (ils appliquent la spécification de l'objet, empêchant tout accès à ses détails d'implémentation et générant une erreur de compilation si une telle tentative est détectée ). Cependant, les méthodes internes de l'objet disposent d'un accès complet à tous les détails de la mise en œuvre. La méthode d’autotest se trouve donc dans une situation unique: il faut qu’elle soit une méthode interne en raison de sa nature (l’autotest est évidemment une méthode de l’objet testé), mais elle doit recevoir toute la discipline du compilateur d’une méthode externe ( il doit être indépendant des détails d'implémentation de l'objet). Peu ou pas de langages de programmation offrent la possibilité de discipliner un objet ' s méthode interne comme s'il s'agissait d'une méthode externe. Il s’agit donc d’un problème de conception de langage de programmation important.
En l'absence d'un support approprié du langage de programmation, la meilleure façon de le faire est de créer un objet compagnon. En d'autres termes, pour chaque objet que vous codez (appelons-le "Big_Object"), vous créez également un deuxième objet compagnon dont le nom consiste en un suffixe standard concaténé avec le nom de l'objet "réel" (dans ce cas, "Big_Object_Self_Test "), et dont la spécification consiste en une seule méthode (" Big_Object_Self_Test.Self_Test (This_Big_Object: Big_Object) return return Boolean; "). L'objet compagnon dépendra alors de la spécification de l'objet principal et le compilateur appliquera pleinement toute la discipline de cette spécification à l'implémentation de l'objet compagnon.