Cajas negras, sistemas y pruebas

Nuestro tema es la programación, más estrictamente, las pruebas unitarias. Acotemos un poco más y digamos que nuestro contexto es la OO (Orientación a Objetos o Object Orientation).

En cierto sentido, las pruebas unitarias son meta-código, es decir, son código que habla del código. Esto ya lo había mencionado ensalzando a la metodología XP [Entre la XP y el RUP]. En aquella ocasión explicaba que las pruebas unitarias son documentación en código y es que, precisamente, eso son. Ser documentación quiere decir que hablan acerca de nuestra aplicación, más estrictamente, hablan del código. Lo elegante del asunto es que ellas mismas son código.

Ahora me viene a la mente aquella idea de la programación neurolingüística en la que el terapeuta puede ayudar a su paciente a resolver un problema, conociéndolo (al problema) casi nada, mediante un metalenguaje en el que se habla de la interacción del problema con el paciente, pero no de los detalles “internos” del problema. Se trata al problema y al paciente como un par de cajas negras y se estudia su interrelación. Parafraseando a Sabines, no lo se de cierto, pero supongo que todas las meta-cosas hacen lo mismo, se ocupan de las interacciones entre objetos, y al menos en el caso de las pruebas unitarias como meta-código así pasa también. Las pruebas describen las relaciones de los objetos entre sí.

Son varias las razones por las que las pruebas unitarias sólo se ocupan de los miembros públicos (es decir, de los objetos como cajas negras), pero quizá la más importante es que, desde un punto de vista descriptivo y de diseño, el cómo funcionan las cosas por dentro es algo que nos preocupa poco, lo importante para un sistema es el cómo funcionan las cosas en relación con otras. Cuando creamos una clase estamos definiendo dos cosas, la primera es su contrato, su apariencia exterior, su comportamiento y es esa apariencia la que intentamos probar con las pruebas, el cómo conseguimos que los objetos que instancían a la clase hagan lo que tienen que hacer es un problema distinto, y en términos de diseño, un problema muy acotado. Al final del cuento, si internamente se toma un camino u otro es algo que a los demás objetos les importa poco, lo importante es qué salidas tiene ante ciertas entradas.

Quizá el lector ya esté pensando en ese autor, menos apreciado de lo que convendría, de la teoría general de sistemas, Ludwig von Bertalanffy.

En efecto, el software como sistema general puede entenderse en función de relaciones entre elementos, y esas relaciones, en su nivel más pequeño, es decir, a nivel de objetos, son descritas y monitoreadas por las pruebas unitarias.

One thought on “Cajas negras, sistemas y pruebas

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s