Esta idea simplemente equivale a un método "Self_Test" dentro del contexto de un diseño basado en objetos u orientado a objetos. Si utiliza un lenguaje compilado basado en objetos como Ada, el compilador marcará todo el código de autoprueba como no utilizado (nunca invocado) durante la compilación de producción, y por lo tanto todo se optimizará. No aparecerá ninguno en el ejecutable resultante.
Usar un método "Self_Test" es una muy buena idea, y si los programadores estuvieran realmente preocupados por la calidad, todos lo estarían haciendo. Sin embargo, un problema importante es que el método "Self_Test" debe tener una disciplina intensa, ya que no puede acceder a ninguno de los detalles de la implementación y, en cambio, debe confiar solo en todos los demás métodos publicados dentro de la especificación del objeto. Obviamente, si la autoprueba falla, la implementación deberá cambiar. La autoprueba debe probar rigurosamente todas las propiedades publicadas de los métodos del objeto, pero nunca depender de ningún modo de los detalles de una implementación específica.
Los lenguajes basados en objetos y orientados a objetos frecuentemente brindan exactamente ese tipo de disciplina con respecto a los métodos externos al objeto probado (imponen la especificación del objeto, impiden cualquier acceso a sus detalles de implementación y generan un error de compilación, si es que existe). intento es detectado). Pero a los propios métodos internos del objeto se les da acceso completo a cada detalle de implementación. Por lo tanto, el método de autoprueba se encuentra en una situación única: debe ser un método interno debido a su naturaleza (la autoprueba es obviamente un método del objeto que se está probando), pero necesita recibir toda la disciplina del compilador de un método externo ( tiene que ser independiente de los detalles de implementación del objeto). Pocos, si los hay, lenguajes de programación proporcionan la capacidad de disciplinar el método interno de un objeto como si fuera un método externo. Así que este es un importante problema de diseño de lenguaje de programación.
En ausencia de un soporte adecuado del lenguaje de programación, la mejor manera de hacerlo es crear un objeto complementario. En otras palabras, para cada objeto que codifiques (llamémoslo "Big_Object"), también creas un segundo objeto complementario cuyo nombre consiste en un sufijo estándar concatenado con el nombre del objeto "real" (en este caso, "Big_Object_Self_Test "), y cuya especificación consiste en un solo método (" Big_Object_Self_Test.Self_Test (This_Big_Object: Big_Object) return boolean; "). El objeto complementario dependerá de la especificación del objeto principal, y el compilador aplicará completamente toda la disciplina de esa especificación contra la implementación del objeto complementario.