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 tiempo de ejecución del sistema) que verifica el programa completo. Y, del mismo modo que tiene un compilador vigilando por encima de su hombro, ¿no querría que estas pruebas le ayudaran desde el principio? Por eso se escriben primero, y se ejecutan automáticamente con cada construcción del sistema. Sus pruebas se convierten en una extensión de la red de seguridad proporcionada por el lenguaje.

Una de las cosas que he descubierto sobre el uso de lenguajes de programación cada vez más poderosos es que estoy dispuesto a probar experimentos más descarados, porque sé que el lenguaje me ahorra la pérdida de tiempo que supone estar persiguiendo errores. El esquema de pruebas de XP hace lo mismo para el proyecto completo. Como el programador conoce sus pruebas siempre cazará cualquier problema que introduzca (y regularmente se añadirán nuevas pruebas), puede hacer grandes cambios cuando lo necesite sin preocuparse de causar un completo desastre. Eso es increíblemente poderoso.