Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 28 — #66
✐
Capítulo 1. Introducción a los Objetos
prácticas mejorará sensiblemente su productividad y fiabilidad.
1.10.1. Escriba primero las pruebas
El proceso de prueba se ha relegado tradicionalmente a la parte final del proyecto,
después de que «consiga tener todo funcionando, pero necesite estar seguro». Implícitamente
ha tenido una prioridad baja, y la gente que se especializa en ello nunca ha
tenido estatus y suele trabajar en el sótano, lejos de los «programadores reales». Los
equipos de pruebas han respondido al estereotipo, vistiendo trajes negros y hablando
con regocijo siempre que encontraban algo (para ser honesto, yo tenía esa misma
sensación cuando encontraba fallos en los compiladores de C++).
XP revoluciona completamente el concepto del proceso de prueba dándole la
misma (o incluso mayor) prioridad que al código. De hecho, se escriben las pruebas
antes de escribir el código que está probando, y las pruebas permanecen con el
código siempre. Las pruebas se deben ejecutar con éxito cada vez que hace una integración
del proyecto (algo que ocurre a menudo, a veces más de una vez al día).
Escribir primero las pruebas tiene dos efectos extremadamente importantes.
Primero, fuerza una definición clara de la interfaz de la clase. A menudo sugiero
que la gente «imagine la clase perfecta para resolver un problema particular» como
una herramienta cuando intenta diseñar el sistema. La estrategia del proceso de
prueba de XP va más lejos que eso - especifica exactamente cual es el aspecto de
la clase, para el consumidor de esa clase, y exactamente cómo debe comportarse la
clase. En ciertos términos. Puede escribir toda la prosa, o crear todos los diagramas
donde quiera describir cómo debe comportarse una clase y qué aspecto debe tener,
pero nada es tan real como un conjunto de pruebas. Lo primero es una lista de deseos,
pero las pruebas son un contrato forzado por el compilador y el programa. Es
difícil imaginar una descripción más concreta de una clase que las pruebas.
Mientras se crean las pruebas, el programador está completamente forzado a elaborar
la clase y a menudo descubrirá necesidades de funcionalidad que habrían sido
omitidas durante los experimentos de diagramas UML, tarjetas CRC, casos de uso,
etc.
El segundo efecto importante de escribir las pruebas primero procede de la propia
ejecución de las pruebas cada vez que hace una construcción del software. Esta
actividad le ofrece la otra mitad del proceso de prueba que es efectuado por el compilador.
Si mira la evolución de los lenguajes de programación desde esta perspectiva,
verá que las mejoras reales en la tecnología giran realmente alrededor del proceso
de prueba. El lenguaje ensamblador sólo se fija en la sintaxis, pero C impone algunas
restricciones de semántica, y éstas le impiden cometer ciertos tipos de errores.
Los lenguajes POO imponen incluso más restricciones semánticas, si lo piensa son
realmente formas del proceso de prueba. «¿Se utiliza apropiadamente este tipo de
datos ¿Se invoca esta función del modo correcto» son el tipo de pruebas que se
llevan a cabo por el compilador en tiempo de ejecución del sistema. Se han visto los
resultados de tener estas pruebas incorporadas en el lenguaje: la gente ha sido capaz
de escribir sistemas más complejos, y han funcionado, con mucho menos tiempo y
esfuerzo. He tratado de comprender porqué ocurre eso, pero ahora me doy cuenta
de que son las pruebas: el programador hace algo mal, y la red de seguridad de las
pruebas incorporadas le dice que hay un problema y le indica dónde.
Pero las pruebas incorporadas que proporciona el diseño del lenguaje no pueden
ir más lejos. En este punto, el programador debe intervenir y añadir el resto de las
pruebas que producen un juego completo (en cooperación con el compilador y el
28
✐
✐
✐
✐