El camino a un mejor programador

Los lenguajes de programación son como los idiomas humanos en muchos sentidos: tienen sintaxis, expresiones comunes, son mejores o peores que otros para expresar ciertas ideas, se pueden «hablar» con mayor o menor fluidez e incluso se puede decir que sus «hablantes» tienen una cierta «cultura» diferente de los «hablantes» de otros lenguajes.

Así, cuando aprendemos un lenguaje nuevo es un error verlo como «una nueva sintaxis»: aprender un lenguaje bien, nos hace cambiar cómo pensamos y cómo resolvemos los problemas. Por ejemplo, digamos que empezamos a aprender Lisp y que sólo conocemos lenguajes imperativos «clásicos» como C o Java. Como parte de un programa que estamos escribiendo, tenemos una función que calcula el valor total a pagar por unos artículos. Los parámetros de entrada son el importe de cada artículo, el número de artículos, el porcentaje de impuesto, y el límite pasado el cual hay que aplicar el impuesto (p.ej.: tenemos 2 artículos a 5 euros cada uno, un impuesto del 10% y un límite de 8 euros; el precio final será 11. Si el límite fuese 15 euros, el precio final sería 10 porque no se aplicaría el impuesto). Una forma de escribirla en Lisp sería la siguiente:

Sin embargo, si escribimos la función así no aprendemos nada nuevo y mostramos nuestro «acento extranjero» al escribir Lisp. Este código no es legible ni para programadores de Java ni para programadores de Lisp, y además no aprovechamos las ventajas del lenguaje, mientras que sufrimos sus desventajas. Simplemente usamos Lisp como «un mal Java». Compárese el anterior código con el siguiente:

Este código se parece más a lo que muchos programadores de Lisp esperarían o escribirían ellos mismos, y a la mayoría de las personas que sepan un poco de Lisp les parecerá más legible y fácil de mantener. La razón es que estamos jugando con las fortalezas de Lisp, en vez de intentar adaptar el lenguaje a nuestros conocimientos previos.

Concretamente, el segundo ejemplo se aprovecha de dos detalles muy comunes en Lisp que no son tan comunes en lenguajes no funcionales:

Sabiendo esto, y que la última expresión de una función Lisp es el valor devuelto por ésta, se puede entender el segundo ejemplo mucho mejor.

Aunque el ejemplo de arriba es bastante simplista, también ilustra que los lenguajes funcionales tienden a hacerte pensar más en el objetivo que en el proceso. Para algoritmos, generalmente una solución en un lenguaje funcional se parece más a la definición matemática. En el primer ejemplo, la implementación de la función está basada en el proceso de calcular. En el segundo, en el significado de las operaciones.

Si lo pensamos en castellano, el primer ejemplo sería algo así:

El segundo ejemplo, en cambio, sería algo así:

Nótese cómo en la segunda explicación podemos dejar para el final la explicación de los valores declarados en el bloque let*. En muchos casos, y siempre que hayamos escogido buenos nombres para esos valores, no hará falta leer el bloque let* para entender la función.

Usar variables que no cambian una vez les hemos asignado un valor, es una buena costumbre porque hace más fácil entender de dónde sale cada valor. Por esa razón, el lenguaje Scala distingue entre dos tipos de variables: var y val. El segundo tipo, que es el más usado con diferencia, declara una variable inmutable, por lo que el compilador nos asegura que no podemos asignar ningún otro valor una vez declarada.

Esto está relacionado con el siguiente apartado, «Diseño de abajo a arriba, funciones pequeñas»: para poder pensar en el significado, muchas de las operaciones tienen que abstraerse en pequeñas funciones.

Otra característica común de la programación en Lisp es intentar acercar el lenguaje a la tarea que se intenta resolver. Una de las maneras de hacerlo es escribir funciones que, aunque sean pequeñas y simples, escondan detalles de implementación que no nos interesen y que suban el nivel de abstracción. La lección aquí es que escribir funciones y métodos de una o dos líneas es útil si suben el nivel de abstracción. No se trata de «esconder código» para no tenerlo a la vista, se trata de hacer olvidar a uno mismo parte de la complejidad de la tarea que está realizando.

Como ejemplo, sigamos con el caso anterior de los precios y los artículos. Una de las operaciones que hacemos es calcular un tanto por ciento. Si suponemos que es una operación que usaremos más de una vez, podría tener sentido abstraer ese cálculo. No nos vamos a ahorrar líneas de código, pero esta versión puede requerir menos esfuerzo mental y ser más fácil de leer (imagínese el siguiente ejemplo en castellano, tal y como hicimos en el anterior apartado):

Calcular un tanto por ciento es trivial, y por escribir la función percentage no estamos ahorrando líneas de código, pero cada segundo que ahorramos en entender trivialidades al leer la fuente es un segundo más que podemos dedicar a asuntos más importantes. Y el tiempo que necesitamos para entender código sin las abstracciones apropiadas, con frecuencia crece exponencialmente, no linealmente, al añadir nuevas faltas de abstracción.

Otra ventaja de abstraer funciones de esta manera es que estas funciones normalmente son bastante fáciles de probar, porque tienden a tener interfaces sencillas y responsabilidades claras. En el caso de lenguajes que tienen una consola interactiva (como Lisp, Python, Ruby y otros) es fácil experimentar con la función y ver lo que hace, facilitando la escritura de pruebas unitarias en cualquier lenguaje. Especialmente si evitamos los efectos colaterales, como veremos en el siguiente apartado.

Los llamados efectos colaterales son uno de los conceptos más importantes de la programación funcional, por no decir que el más importante. Es lo que diferencia los lenguajes puramente funcionales de los lenguajes funcionales no puros. Incluso los programadores de los lenguajes que no son puramente funcionales (como Lisp) generalmente intentan evitar efectos colaterales.

Un efecto colateral es cualquier cambio que una función produce fuera del ámbito de la función en sí. Por ejemplo, una función que modifique una variable que ha recibido como parámetro (es decir, «parámetros de entrada/salida») o que modifique variables globales o cualquier otra cosa que no sean variables locales a la función está produciendo efectos colaterales. Esto incluye cualquier tipo de entrada/salida, como leer o escribir ficheros o interactuar con la pantalla, el teclado o el ratón.

¿Por qué es tan importante evitar efectos colaterales? De nuevo, como en el caso de las pequeñas funciones que suban el nivel de abstracción, evitar un solo efecto colateral no es una ventaja muy grande. Sin embargo, evitar efectos colaterales como regla general hace que los programas sean más fáciles de entender y mantener, y que haya menos sorpresas. La razón es que evitar efectos colaterales garantiza que ningún error en la función pueda afectar a nada más. Si además no hacemos referencia a nada externo a la función, como variables globales, tenemos una garantía extra importantísima: la función es independiente del resto del código, lo que significa que ningún fallo del resto del programa puede afectar a nuestra función, y que podemos probar la función independientemente del resto del código, lo cual no sólo es práctico, sino que hace más fácil asegurarse de que cubrimos todos los casos posibles de la función con baterías de pruebas.

Veamos un ejemplo de efectos colaterales en Python. El método sort, desgraciadamente, modifica la lista sobre la que se llama. Esto puede producir sorpresas desagradables, como veremos en el primer ejemplo. Digamos que estamos escribiendo un programa para gestionar competiciones de carreras y escribimos una función best_time que recibe una lista de números y devuelve el menor (obviamos la existencia de la función min para hacer el ejemplo más ilustrativo):

Una forma de resolver este problema es usar la función sorted en vez del método sort:

En Ruby normalmente se usa la convención de añadir un «!» al final del nombre del método si éste produce efectos colaterales (otra convención que se puede apreciar en el ejemplo es cómo los métodos que devuelven verdadero/falso terminan en «?»). El ejemplo de arriba se podría traducir a Ruby de la siguiente manera:

Por último, evitar efectos colaterales permite a las funciones usar una técnica de optimización llamada «memorización» (memoization en inglés). Esta técnica consiste en recordar el valor retornado por la función la primera vez que se llama. Cuando se vuelve a llamar a la función con los mismos parámetros, en vez de ejecutar el cuerpo de la función, se devuelve el valor recordado. Si la función no produce ningún efecto colateral, esta técnica es perfectamente segura porque está garantizado que los mismos parámetros de entrada siempre producen el mismo resultado. Un ejemplo muy sencillo de memorización en Javascript es la siguiente implementación de la serie de Fibonacci:

Si se copia este código en una consola Javascript (digamos, Node) y se hacen distintas llamadas a la función fibonacci, se podrá comprobar (gracias a los mensajes impresos por console.log) que cada posición de la serie sólo se calcula una vez.

En lenguajes dinámicos como Python, Ruby o Javascript, es relativamente sencillo escribir una función que reciba otra función como parámetro y le aplique la técnica de «memorización». El siguiente apartado explora la técnica de manipular funciones como datos.

Otra de las características comunes de los lenguajes funcionales es tratar a las funciones como «ciudadanos de primera clase». Es decir, las funciones son valores más o menos normales que se pueden pasar como parámetros, asignar a variables y devolver como resultado de la llamada a una función. Las funciones que utilizan esta característica, es decir, que manipulan o devuelven funciones, reciben el nombre de funciones de orden superior. Afortunadamente, muchos lenguajes populares tienen este tipo de funciones.

La primera vez que uno se encuentra funciones de orden superior puede pensar que sus usos son limitados, pero realmente tienen muchas aplicaciones. Por un lado, tenemos las funciones y métodos que traiga el lenguaje de serie, por lo general de manejo de listas. Por otro, tenemos la posibilidad de escribir nuestras propias funciones y métodos de orden superior, para separar o reutilizar código de manera más efectiva.

Veamos un ejemplo de lo primero en Ruby. Algunos de los métodos de la clase Array reciben una función como parámetro (en Ruby se los llama bloques), lo que permite escribir código bastante compacto y expresivo:

El código equivalente que habría que escribir para conseguir el mismo resultado sin funciones de orden superior es bastante más largo y difícil de leer. Además, si quisiéramos hacer operaciones parecidas variando la condición (digamos, en una parte del código queremos comprobar si todas las palabras tienen menos de cinco letras, y en otra queremos comprobar si todas las palabras se componen exclusivamente de letras, sin números u otros caracteres) el código empeoraría rápidamente.

Escribir nuestras propias funciones tampoco tiene que ser difícil, ni usarse en casos muy especiales. Pueden ser usos tan comunes y sencillos como el siguiente ejemplo en Javascript:

A partir de Ecmascript 5, la clase Array añade varios métodos de orden superior que son comunes en la programación funcional.

La última característica de lenguajes funcionales que exploraremos es la evaluación perezosa. No hay muchos lenguajes que incluyan evaluación perezosa, pero se puede imitar hasta cierto punto, y saber cómo funciona puede darnos ideas e inspirarnos a la hora de diseñar nuestros propios sistemas. Uno de los relativamente pocos lenguajes que incluye evaluación perezosa es Haskell.

La evaluación perezosa consiste en no hacer cálculos que no sean necesarios. Por ejemplo, digamos que escribimos una función que genere recursivamente una lista de 10 elementos, y otra función que llame a la primera, pero que sólo use el valor del cuarto elemento. Cuando se ejecute la segunda función, Haskell ejecutará la primera hasta que el cuarto elemento sea calculado. Es decir: Haskell no ejecutará, como la mayoría de los lenguajes, la primera función hasta que devuelva su valor (una lista de 10 elementos); sólo ejecutará la función hasta que se genere el cuarto elemento de la lista, que es lo único que necesita para continuar la ejecución del programa principal. En este sentido, la primera función es como una expresión matemática: inicialmente Haskell no conoce el valor de la expresión, y sólo calculará la parte de ésta que necesite. En este caso, los cuatro primeros elementos.

¿Cuál es la ventaja de la evaluación perezosa? En la mayoría de los casos, eficiencia. En otros casos, legibilidad. Cuando no tenemos que preocuparnos por la memoria o ciclos de CPU usados por nuestra función, podemos hacer que devuelvan (teóricamente) listas o estructuras infinitas, las cuales pueden ser más fáciles de leer o implementar en algunos casos. Aunque no es el ejemplo más claro de legibilidad de evaluación perezosa, entender la siguiente implementación de la serie de Fibonacci, aclarará la diferencia con la evaluación estricta. Nótese que la función calcula la serie entera, es decir, una lista infinita:

Normalmente la función es imposible de entender de un primer vistazo si no estamos familiarizados con la programación funcional y la evaluación perezosa, pero hay varios puntos que nos ayudarán:

Así, lo que ocurre es:

Estos pasos no se ejecutan indefinidamente: se irán ejecutando hasta que se obtenga el elemento de fibs que se necesite. Es decir, si asignamos fibs a una variable pero nunca la usamos, el código no se ejecutará en absoluto; si usamos el valor del tercer elemento de la serie en algún cálculo, sólo se ejecutarán los dos primeros pasos descritos arriba; etc. En ningún caso se intenta ejecutar fibs hasta que devuelva «el valor completo».

La evaluación perezosa se puede ver como aplicar la técnica de «memorización» automáticamente a todo el lenguaje. Un posible uso es calcular tablas de valores que son lentos de calcular: en algunos casos podríamos cargar una tabla precalculada en memoria, pero el coste puede ser prohibitivo si la tabla es grande o potencialmente infinita.

Aprender lenguajes nuevos, especialmente de paradigmas con los que estamos menos familiarizados, nos puede enseñar muchas cosas sobre programación en general. Este proceso de aprendizaje nos hará mejores programadores, y muchas de esas lecciones serán aplicables a todos los lenguajes que conozcamos, no sólo a los lenguajes similares al que acabemos de aprender. En particular, los lenguajes funcionales son suficientemente accessibles y similares a los lenguajes más populares como para enseñarnos muchas lecciones útiles.

Para tener una cierta confianza en que la aplicación resuelve un cierto problema se llevan a cabo pruebas funcionales; estas resuelven un ejemplo concreto y representativo simulando las acciones del usuario y verificando que la reacción de la aplicación es la esperada.

Las pruebas funcionales han de mantenerse al día y evolucionar con los cambios de la aplicación y sus requisitos. Otro de los retos es que sean correctas, es decir, que el comportamiento que estén verificando sea realmente el que se requiere de la aplicación.

Es crucial que las pruebas funcionales estén automatizadas; lo típico es escribirlas en el mismo lenguaje de programación de la aplicación. Esto nos permite ejecutar un gran número de ellas de forma sistemática y tras cada cambio, con lo que también nos protegerán de que algo que funcionaba deje de hacerlo, es decir, de posibles regresiones.

Si bien podríamos considerar que nuestra prueba funcional en Java es la documentación principal donde se registran los criterios de aceptación; dependiendo de quién vaya a consumirla, esto puede o no ser una opción. Además, conseguir reemplazar la legibilidad de un párrafo en español con una prueba en el lenguaje de programación es todo un reto, particularmente si el lenguaje de programación es tan prolijo como Java.

En consecuencia, en la mayoría de los proyectos es necesario documentar los requisitos de manera más textual.

Una forma de intentar obtener lo mejor de las dos alternativas es conectar la documentación a la aplicación de tal forma que en todo momento sea automático y evidente verificar el cumplimiento de cada uno de los requisitos expresados, lo que nos ayudará a mantener la documentación sincronizada con la aplicación y con el cliente.

La documentación, junto con la capacidad de procesarla para su verificación, servirá así de batería de pruebas funcionales; si ejecutamos esta batería con frecuencia (idealmente con cada cambio) y la mantenemos veraz, estaremos garantizando el correcto funcionamiento de la aplicación… para la definición especificada.

Concordion es una de las herramientas que nos pueden ayudar a conectar la documentación con la aplicación; en Concordion los criterios se escriben en HTML al que se añaden algunas marcas que comienzan con concordion:

Vemos que hemos expresado el ejemplo en forma de condición y consecuencia que se debe verificar. Los atributos concordion:set y concordion:assertEquals conectan el documento al método de la clase de respaldo, escrita en Java, String articleListAfterAdding(String url), que se encargará de hacer lo que dice el texto.

Al ejecutar ListaPermaneceVaciaTest, Concordion generará un documento HTML con el texto anterior en el que se indicará si se cumple la aserción resaltándola en verde o rojo.

En las secciones anteriores nos hemos permitido hacer un poco trampas que deberíamos descubrir antes de cerrar el artículo. Supongamos que el desarrollador, al escribir el código de la aplicación comete una equivocación por no entender debidamente lo que necesita el cliente; decide hacer una aplicación que añade los artículos a una lista de artículos a leer. Nuestras pruebas funcionales deberían detectar este error marcando la aserción en rojo. Sin embargo, nos encontramos con que la pruebas pasan.

Evidentemente, nuestras pruebas funcionales no son correctas, esto se debe a que estamos verificando que el estado de la lista de artículos es el mismo después de entrar el nuevo artículo que antes de entrarlo, y la prueba verifica la condición antes de que la aplicación tenga tiempo de añadir erróneamente artículos a la lista.

Probar sistemas asíncronos es lo suficientemente complejo como para justificar un artículo en sí mismo, pero si enumeramos algunas de las opciones, de más rápidas y sencillas de implementar a menos, tenemos:

En nuestro ejemplo sabemos que, cada vez que la aplicación responde a la entrada de un nuevo artículo, lo último que hace es borrar la caja de texto. Por lo tanto, podemos utilizar este evento como punto de sincronización, es decir, antes de verificar que la lista permanece vacía esperaremos a que la caja se haya borrado.

La documentación activa es una forma de probar funcionalmente un programa en el que cada criterio de aceptación se enuncia con un texto que se enlaza a la ejecución de código que verifica el criterio. Al ejecutarla, se produce un resultado que indica, de forma legible para los expertos del dominio, qué criterios de aceptación cumple el programa y qué criterios no cumple. Como casi todo, su uso debería adaptarse a la composición del equipo y la complejidad del proyecto.

Aunque es normal que al acercarse el final de cada ciclo de desarrollo se intensifique el esfuerzo de pruebas (especialmente las manuales), es un error mayúsculo no haber probado desde el principio del desarrollo. Esto no es un tópico o una consideración teórica o académica: no probar desde el principio del ciclo de desarrollo tiene muchas desventajas. Por ejemplo:

Como tarde o temprano se tendrá que probar el resultado del trabajo, mejor empezar temprano porque es menos costoso (en tiempo y esfuerzo mental) y los resultados son mejores. Escribir código sin probar es simplemente irresponsable y una falta de respeto con respecto a los usuarios del producto y al resto de los miembros del equipo, especialmente los que tengan que mantener el código después y cualquier miembro del equipo que use directa o indirectamente el código sin probar.

Esto es un problema bastante común, sobre todo cuando se empiezan a hacer pruebas. Las pruebas automáticas son, de alguna manera, una descripción de lo que se espera que el programa haga. Una especificación en código, por así decirlo. Como tal, sólo debe describir el comportamiento que esperamos que no cambie. Si somos demasiado específicos o exigentes en las comprobaciones de nuestras pruebas, éstas no sólo evitarán que introduzcamos fallos en el código, sino también que podamos hacer otro tipo de cambios.

Por ejemplo, digamos que estamos escribiendo una aplicación de tareas pendientes muy sencilla. La clase que representa una lista de tareas se llama BrownList, y podría tener una pinta así en Ruby:

Ahora, para probar que el método add_brown funciona, puede que se nos ocurra conectarnos a la base de datos y comprobar si tiene la fila correcta. En la gran mayoría de los casos esto es un error. Para entender por qué, hay que darse cuenta de que las pruebas definen qué significa que el código funcione. Así, si las pruebas usan detalles de la implementación, se estará definiendo de manera implícita que el programa sólo «funciona bien» si mantiene los mismos detalles de implementación. Lo cual es, naturalmente, un error, porque no permite que el código evolucione.

En este ejemplo concreto, hay muchos casos en los que esta prueba fallaría, a pesar de que el código podría estar funcionando perfectamente:

Las pruebas no deben limitarnos cuando reorganizamos código o cambiamos detalles de implementación. De hecho, una de las ventajas de tener pruebas automáticas es que cuando reorganicemos código, sabremos si estamos haciendo algo mal porque las pruebas fallarán. Si no estamos seguros de que cuando una prueba falla es porque hay un problema en el código, nuestras pruebas no nos están ayudando. Al menos, no todo lo que deberían.

Lo que queremos comprobar en la prueba es, realmente, si hay una nueva tarea añadida. Una manera de probarlo es usar el método pending_browns. Uno podría pensar que no es una buena idea porque, si hay un error en add_brown y otro en pending_browns que se cancelen mutuamente, las pruebas pasarán igualmente. Eso es verdad, pero en la mayoría de los casos no importa, porque desde el punto de vista del usuario de la clase, ésta se comporta como debería. Cuando descubramos el fallo, lo podremos arreglar no sólo sin tener que cambiar las pruebas o el código que llama a BrownList, sino sin que haya habido ningún cambio en el comportamiento de BrownList desde el punto de vista de los usuarios.

Para terminar de ilustrar este consejo, imaginemos ahora que escribimos una interfaz web para nuestra aplicación de tareas pendientes. Si queremos comprobar que la interfaz web funciona correctamente, una (mala) idea que puede pasarnos por la cabeza es comparar el HTML de la página con el HTML que esperamos. Si comparamos el HTML completo (o una captura de pantalla), nuestras pruebas serán muy, muy frágiles. Por ejemplo, nuestras pruebas fallarán cuando hagamos cualquiera de estos cambios:

Si nuestras pruebas comparan la salida HTML exacta, implícitamente estamos definiendo nuestra aplicación no como una aplicación web con ciertas características, sino como una aplicación que genera ciertas cadenas de HTML. Ya que al usuario no le importa el HTML generado, sino que la aplicación funcione, podemos ver que este enfoque no es el más apropiado.

Una forma mucho mejor de probar una aplicación web es buscar las partes interesantes. Por ejemplo, comprobar que el título de la nueva tarea aparece en el contenido de la página justo después de crearla. O comprobar que ya no está ahí después de borrarla. O comprobar que, al renombrar una tarea, el título antiguo ya no aparece, pero sí el nuevo. Sin embargo, hacer esas comprobaciones directamente puede ser tedioso y puede añadir algo de fragilidad a nuestras pruebas, por lo que lo mejor es desacoplar los detalles del HTML generado de las comprobaciones que queremos hacer. Una de las técnicas para conseguir esto se conoce como PageObjects, pero explorar PageObjects va mucho más allá del objetivo de este artículo.

Como resumen de este consejo, podemos decir que las pruebas no sólo deben fallar cuando hay algún problema, sino que también deben pasar mientras no haya ninguno.

Las pruebas no son un añadido al código, son parte integrante de éste. Asimismo, ejecutarlas es parte del ciclo normal de desarrollo. Si no las ejecutamos con frecuencia, no van a ser tan efectivas. Primero, porque cuando haya fallos, es probable que sea más de uno. En ese caso, será más difícil encontrar el origen de éstos. ¿Es un solo error el que provoca todos los fallos en las pruebas, uno por cada prueba? Segundo, porque si hemos hecho muchos cambios desde la última vez que ejecutamos las pruebas, tendremos más código que revisar en busca del problema.

Ejecutar las pruebas con frecuencia (idealmente, después de cada cambio que hacemos) hace que sea muy fácil encontrar la causa del error, porque lo único que puede haber sido la causa de los fallos son los cambios desde la última vez que las ejecutamos. Si ejecutamos las pruebas antes de mandar nuestros cambios al control de versiones, y vemos que una de las pruebas falla, será suficiente ejecutar git diff (o svn diff o similar) para ver qué cambios deben de haber producido el problema. Además, cuanto más alta sea la frecuencia con la que ejecutemos las pruebas, más seguros estaremos de que el código funciona correctamente. En la medida de lo posible, en el mundo de la programación es mejor evitar la fé: trabajaremos más tranquilos y con más confianza si podemos demostrar que el código funciona en los casos cubiertos por las pruebas.

El último punto importante de este consejo es tener una máquina «neutral» que ejecute las pruebas automáticas que tengamos, cada vez que alguien manda un cambio al control de versiones. Las ventajas son muchas:

Véase el artículo de Martin Fowler [fowlerci] sobre integración continua para más información.

Otro problema bastante común es escribir pruebas sin controlar el entorno en el que se ejecutan. En parte esta (mala) costumbre viene de la creencia de que las pruebas tienen que adaptarse a diferentes circunstancias y ser robustas como los programas que escribimos. Esto es un malentendido.

Volvamos al ejemplo anterior de la aplicación de tareas pendientes. Cuando escribimos las pruebas, los pasos no fueron:

Los pasos fueron:

Esta diferencia es fundamental. Uno podría pensar que la primera prueba es mejor porque «funciona en más casos». Sin embargo, esto es un error por las siguientes razones:

Si queremos probar ciertos casos de datos iniciales, es más claro y más fiable probar esos casos expresamente y por separado. Tendremos la ventaja de que estará claro al leer las pruebas qué casos cubrimos, y ejecutar las pruebas una sola vez nos hará estar seguros de que todos los casos que nos interesan funcionan perfectamente. Como regla general, cualquier incertidumbre o indeterminismo sobre la ejecución o resultados de las pruebas que podamos eliminar, debe ser eliminado.

Podemos terminar este consejo con una reflexión: las pruebas no son mejores porque pasen con más frecuencia, sino porque demuestren que un mayor número de casos interesantes funcionan exactamente como queremos.

Cuando empezamos a escribir pruebas, algo que necesitamos con frecuencia son datos iniciales o de prueba (en inglés, fixtures). Si no tenemos una forma fácil de crear esos bancos de datos para cada prueba, tendremos la tentación de tener un solo conjunto de datos iniciales que usaremos en todas las pruebas de nuestro proyecto. Aunque en algunos casos pueda resultar práctico compartir datos de prueba entre algunas pruebas, esta costumbre puede traer un problema añadido.

A medida que escribimos nuevas pruebas, éstas necesitarán más datos de contraste. Si añadimos estos datos a nuestro único conjunto de datos iniciales, cabe la posibilidad de que algunas de las pruebas antiguas empiece a fallar (p.ej. una prueba que cuente el número de tareas en el sistema). Si ante este problema reescribimos la prueba antigua para que pase con el nuevo conjunto de datos, estaremos haciendo más complejas nuestras pruebas, y además corremos el riesgo de cometer un fallo al reescribir la prueba antigua. Por no mencionar que si seguimos por este camino, puede que en la siguiente ocasión tengamos que reescribir dos pruebas. O cinco. O veinte.

Todo esto está relacionado, en cierta manera, con el problema descrito en el anterior apartado: pensar en las pruebas como pensamos en el resto del código. En este caso, pensar que tener más datos de prueba es mejor, porque se parecerá más al caso real en el que se ejecutará el programa. Sin embargo, en la mayoría de los casos esto no representa ninguna ventaja, pero sí que tiene al menos una desventaja: cuando alguna prueba falle y tengamos que investigar por qué, será más difícil encontrar el problema real cuantos más datos haya. Si podemos escribir nuestras pruebas teniendo un solo objeto de prueba, o incluso ninguno, mejor que mejor.

El apartado sobre ejecutar las pruebas con frecuencia ya mencionaba que las pruebas son parte integrante del código. Aunque no funciona exactamente de la misma manera ni tienen las mismas propiedades, sí que se tienen que mantener con el mismo cuidado y esfuerzo con el que mantenemos el resto del código.

Este apartado hace hincapié en que tenemos que hacer lo posible para facilitar la escritura de pruebas. Éstas no son una necesidad molesta a la que tenemos que dedicar el menor tiempo posible: como parte integrante de nuestro código se merece la misma dedicación que el resto. Así, nuestro código de prueba debe ser legible, conciso y fácil de escribir. Si cuesta escribir pruebas, ya sea en tiempo, esfuerzo mental o líneas de código, tenemos un problema que debemos resolver, ya sea reorganizando código, escribiendo métodos de conveniencia o usando cualquier otra técnica que nos ayude. Desgraciadamente, muchos desarrolladores piensan que es normal que sea costoso escribir pruebas y no hacen nada por mejorar la situación. En última instancia, esto hace que el equipo escriba menos pruebas, y de peor calidad.

Veamos un caso concreto. Digamos que queremos probar la interfaz web de nuestra aplicación de tareas pendientes. Una de las primeras pruebas que escribiríamos aseguraría que crear una tarea simple funciona. Una primera implementación podría quedar así:

Aunque aisladamente, este código es relativamente fácil de leer y entender, tiene varios problemas:

Una alternativa mucho mejor sería la siguiente:

Las mejoras de la segunda versión son las siguientes:

Como se puede ver, una simple reorganización del código (del mismo tipo que haríamos con el código principal del programa) puede tener un impacto muy grande en la facilidad de mantenimiento de nuestras pruebas.

La necesidad de facilitar la escritura de pruebas se extiende a todas las tareas relacionadas con probar nuestro código, no sólo mantener el código de pruebas automáticas. Digamos que escribimos un programa cliente-servidor. Si cada vez que encontramos un problema no somos capaces de depurarlo, o de asegurar si está de verdad arreglado o no porque no tenemos una forma fácil de probar el cliente o el servidor por separado, tenemos un problema. Una de las varias soluciones posibles es tener un cliente de prueba con el que podamos enviar al servidor cualquier petición que se nos ocurra, y un servidor de prueba con el que podamos enviar al cliente cualquier respuesta que se nos ocurra. Herramientas para capturar fácilmente el tráfico entre cliente y servidor también pueden ahorrarnos mucho tiempo a la larga.

Al fin y al cabo, estamos hablando de la calidad de nuestro trabajo, no en un sentido abstracto o teórico, sino en el sentido más pragmático desde el punto de vista del usuario. Si no podemos comprobar que nuestro programa se comporta debidamente, nos quedarán muchos fallos por descubrir, y por tanto que arreglar, que llegarán a los usuarios finales.

El último consejo es el más avanzado, y es el consejo con el que hay que tener más cuidado al aplicarlo. La tendencia natural al crear entornos de prueba es replicar algo lo más parecido posible al entorno real, usando las mismas bases de datos, los mismos servidores y la misma configuración. Aunque esto tiene sentido y es necesario en pruebas de aceptación y pruebas de integración
[Las pruebas de integración son las más completas que hacemos, que determinan si el proyecto, como un todo, funciona desde el punto de vista del usuario.]
, puede ser bastante contraproducente en pruebas unitarias y similares, en las que sólo queremos probar componentes relativamente pequeños.

Depender de servicios externos como una base de datos, un servidor web, una cola de tareas, etc. hace que las pruebas sean más frágiles, porque aumentan las posibilidades de que fallen por una mala configuración, en vez de porque hemos encontrado un problema en el código. Como en la mayoría de los tipos de pruebas, como las unitarias, sólo queremos probar que cierto componente concreto funciona correctamente, no hace falta que lo integremos con el resto de los componentes. En muchos casos, podemos reemplazar esos componentes con versiones «de pega» que se comporten como nos haga falta para cada prueba.

Un ejemplo claro de las ventajas de usar componentes «de pega» es el desarrollo y prueba de una aplicación que usa una API, tanto en el caso de que escribimos sólo el cliente como en el caso de que escribimos tanto el cliente como el servidor. Aunque para hacer pruebas de integración deberíamos usar el servidor real, la mayoría de las pruebas tendrán un ámbito más limitado (bien sean pruebas unitarias, o pruebas funcionales que sólo cubran el comportamiento del cliente). Para éstas sabemos, al tener la documentación de dicha API:

Armados con este conocimiento, podemos diseñar pruebas que no dependen del servidor. No depender del servidor tiene varias ventajas, entre otras:

No todo son ventajas, claro. Si el servidor introduce cambios que rompen la compatibilidad con la documentación que tenemos, esos fallos no se descubrirán hasta las pruebas de integración. De manera similar, si nuestras pruebas dependen de un comportamiento concreto, documentado o no, y este comportamiento cambia, de nuevo no detectaremos estos fallos hasta las pruebas de integración.

Veamos un ejemplo más concreto. Digamos que escribimos un programa que utiliza la API pública de Kiva, una organización que permite, mediante microcréditos, prestar dinero a personas que lo necesitan. Nuestra aplicación mostrará los últimos préstamos listados en la web de Kiva (digamos, 50), información que obtenemos usando la llamada /loans/newest. Sin embargo, hay varios casos que son muy difíciles de probar con un servidor real:

Probar todos esos casos a mano con el servidor real de Kiva es prácticamente imposible, principalmente porque no podemos hacer que el servidor devuelva las respuestas necesarias para reproducir cada caso. Si todas nuestras pruebas dependen del servidor no podremos estar seguros de si el código funciona bien. Sin embargo, todos estos casos son muy fáciles de probar si evitamos conectarnos al servidor real. Los casos mencionados arriba se podrían escribir de la siguiente manera en Javascript, usando Jasmine:

Probar programas es una tarea importante pero bastante difícil de hacer correctamente. Sin embargo, si empezamos a hacer pruebas desde el comienzo del proyecto, las ejecutamos con frecuencia y nos preocupamos de que sean fáciles de mantener, nuestras probabilidades de producir programas robustos serán mucho más altas.

El primer problema de la calidad es definirla. Hay muchas definiciones, pero mi preferida en el contexto de la ingeniería de software es «adecuación al uso». Uno de los problemas de la definición es que es muy vaga pero, paradójicamente, el propio hecho de ser tan vaga es lo que la hace útil. La calidad es un asunto muy complejo, por lo que simplificarlo, lejos de ayudarnos a entender, sólo nos dará la ilusión de que lo entendemos. Y la ilusión de entendimiento es muy peligrosa porque hace que nos resistamos al aprendizaje real.

El segundo problema de la calidad es hacer que todos los interesados compartan lo que entienden por ésta. Este entendimiento compartido nos ayudará a centrarnos en los objetivos importantes, que son las necesidades del cliente del proyecto. Esto no significa que sólo sean importantes los aspectos que el cliente menciona: con frecuencia, los clientes dan por sentadas una serie de propiedades (eficiencia, fiabilidad, etc), y nuestro trabajo es asegurarnos de que éstas se cumplen tanto como los requisitos explícitos. Esto es, la calidad necesita de aspectos técnicos como código rápido o diseño simple, pero éstos deben estar supeditados a las necesidades y los deseos del cliente, implícitos y explícitos.

Como ya expone el apartado anterior, es imposible dar una «receta mágica» para mejorar la calidad. De hecho, intentar mejorar la calidad simplemente siguiendo una lista de pasos es un camino casi seguro hacia el fracaso. No importa qué pasos sigamos, qué hayamos oído de ellos o quién los haya recomendado: nuestra única vía para alcanzar un buen nivel de calidad es usar nuestra experiencia y conocimiento del contexto para decidir qué es lo que nos ayudará en cada momento. Tenemos que ser conscientes de lo que hacemos y tomar el control de nuestras decisiones.

Sin embargo, sí se pueden dar guías para mejorar la calidad. Por ejemplo: mantener siempre el qué, no el cómo, como la guía de todo lo que hacemos; mantener el escepticismo y cuestionar cómo hacemos las cosas y por qué; estar preparado para cambiar cómo trabajamos y luchar contra la «programación de culto al cargo»
[Hacer las cosas de cierta manera simplemente porque lo hemos hecho o visto antes, sin entender por qué son así o qué utilidad tienen. Ver Cargo Cult Programming en Wikipedia.]
; no creer en la tecnología como el centro de lo que hacemos; darse cuenta de que lo principal no es hacer código bonito o fácil de entender, sino resolver problemas
[Los buenos profesionales hacen las dos cosas, pero es más profesional tener más de lo segundo que más de lo primero.]
; no creer que los problemas tengan una solución única o mejor.

Esto no quiere decir que las herramientas, técnicas y costumbres no sean útiles. En absoluto. Lo que sí significa es que éstas nos ayudarán según qué contextos, según qué proyectos, según qué equipos y según qué clientes, pero nunca en todos los casos. Los otros artículos de este libro describen algunas de estas técnicas y herramientas, que son muy útiles y todo buen profesional debe conocer y dominar, pero uno de los mensajes principales de este artículo es que conocer y adaptarse al contexto es importante, y que aplicar ciegamente cualquiera de estas técnicas o herramientas es un error.

Para ilustrar las ideas de este artículo, y como inspiración para ayudar a pensar fuera de cánones más académicos, los siguientes apartados muestran una serie de ejemplos de situaciones junto con sugerencias de posibles soluciones. Obviamente no puede haber solución única o «correcta» en estos ejemplos, entre otras razones porque ninguna descripción literaria puede dar toda la información necesaria para tomar una buena decisión.

Como regla general, tener procesos y reglas ayuda a los equipos de desarrollo a trabajar más eficientemente. Por una parte, facilita que nos concentremos en lo que estamos haciendo y no en el cómo
[Si siempre hacemos ciertas cosas de la misma manera y ésta funciona razonablemente bien, no tenemos que gastar tiempo ni energía decidiendo cómo hacerlas.]
. Por otra, facilita la automatización.

Sin embargo, los procesos y las reglas pueden quedarse obsoletos. Por ejemplo, digamos que uno o dos miembros del equipo causan problemas con la integración continua: con frecuencia hacen cambios que hacen fallar a la batería de pruebas y no tienen disciplina para escribir pruebas. Ante esta situación, decidimos que cada cambio enviado al repositorio debe contener alguna modificación a algún fichero de pruebas. La medida funciona más o menos bien, esos miembros del equipo empiezan a tomarse las pruebas más en serio, y así aumentamos la productividad del equipo con ella.

Ahora bien, todas las reglas tienen partes buenas y partes malas, como todo. Esta medida concreta puede ser molesta cuando simplemente queramos arreglar una falta de ortografía en un comentario, actualizar la documentación, o reformatear el código (ya que nuestro cambio no modificaría ningún fichero de pruebas). Por tanto, si en algún momento esos miembros del equipo se marchan o llegan al punto de escribir buenas pruebas y no necesitar la anterior medida, puede que llegue el momento de eliminar esta regla. Mantener y seguir reglas simplemente porque «siempre han funcionado» es caer en la tentación de seguir el «culto al cargo».

Una de las constantes en los artículos de este libro es el uso de pruebas automáticas. Aunque es desde luego una de las prácticas más recomendadas y útiles, también es verdad que con frecuencia tenemos que trabajar con código legado (es decir, sin pruebas). En esos casos, ¿qué hacemos?

Por ejemplo, digamos que nos unimos a un equipo que no tiene cultura de pruebas automáticas, y vamos retrasados con la siguiente entrega. Una parte concreta del código está dando bastantes problemas, y las pruebas manuales (la manera en la que el equipo prueba el código) no están encontrando suficientes fallos, o no lo suficientemente pronto. Aunque automatizar las pruebas es probablemente la mejor idea a largo plazo, no hay ninguna regla exenta de excepciones
[Aunque uno podría decir que «no hay ninguna regla exenta de excepciones» también tiene excepciones…]
. Puede que el equipo no tenga suficiente experiencia en pruebas automáticas como para que introducirlas mejore la situación antes de la entrega. Puede que las partes críticas del proyecto en el que trabajamos no sean fáciles de probar de manera fiable con pruebas automáticas, y empeñarnos en poner énfasis en éstas a toda costa no ayude al equipo en el contexto de esta entrega. Puede que la tensión de ir retrasados haga al equipo ser «optimistas» al escribir pruebas, y las pruebas den un falso sentido de seguridad. Puede que los que toman las decisiones no estén convencidos, y que a corto plazo no valga la pena gastar tiempo y energía en convencerlos. Y puede que hayamos convencido a los que toman las decisiones, pero el equipo no esté convencido, e intentar forzarlos a escribir pruebas sólo vaya a provocar un bajón de moral y un conjunto de pruebas automáticas de muy mala calidad.

Y si por la razón que sea llegamos a la conclusión de que intentar implantar pruebas automáticas para la próxima entrega no es una buena idea, ¿qué podemos hacer? Una de las posibilidades es empezar haciendo más efectivo al equipo sin cambiar radicalmente su filosofía de trabajo. Por ejemplo, puede que tras analizar la situación descubramos que esa parte del programa es más difícil de probar de manera manual porque no da suficiente información. Quizás añadir una opción «escondida» que haga esa parte menos opaca puede ser suficiente hasta la fecha clave. O simplemente mejorar la comunicación entre los miembros del equipo. Porque, entre otras cosas, siempre es positivo respetar la manera de trabajar de un equipo («que siempre ha funcionado»): no sólo mejora las relaciones entre sus miembros, sino que ayuda a ganarse su respeto y atención, que serán necesarios más tarde para poder implementar cambios grandes como desarrollo dirigido por pruebas o simplemente escribir pruebas automáticas. Y mientras tanto, podemos ir enseñando poco a poco al equipo a automatizar las pruebas para ir cambiando a un modelo (posiblemente) más escalable.

Cuando se desarrolla software normalmente se tienen especificaciones. Pueden ser formales (un documento) o informales (el conocimiento compartido del equipo). El objetivo de las especificaciones es poder concentrarse en la solución técnica sin tener que estar preguntando continuamente a los clientes o al resto del equipo sobre el enfoque a la hora de resolver el problema. Pero, de nuevo, las especificaciones son sólo una herramienta, y cumplir más a rajatabla con las especificaciones no tiene por qué garantizar una mayor calidad del proyecto una vez completado.

Digamos que estamos desarrollando el software que conduce un coche automático. Uno de los requisitos del coche es que pare en los pasos de peatones cuando detecte que una persona está cruzando. Sin embargo, mucha gente no cruza por los pasos de peatones, así que el coche sería mucho más seguro si no dependiera de éstos, sino que pudiera detectar por sí mismo si tiene algo delante que podría llegar a atropellar. Es decir, las especificaciones son una herramienta muy útil, pero nunca son el objetivo final del desarrollo de software. Las personas que escriben las especificaciones cometen errores, las condiciones del proyecto cambian, etc. Mantener siempre el escepticismo y una visión más completa de nuestros objetivos, y no dejarnos llevar por el «no es mi trabajo», el «no me pagan por esto» o el «yo sólo hago lo que me dicen», es mucho más importante que cumplir la especificación diligentemente. Dicho de otra manera, nuestro trabajo no es escribir software que cumple a rajatabla una descripción textual de un problema. Es hacer software útil y resolver problemas.

Una parte importante de la calidad es, por supuesto, tener código mantenible. El código mantenible normalmente se consigue con código legible y un diseño simple. Sin embargo, y como muchas otras cosas, estos dos aspectos son sólo una herramienta para conseguir calidad: un código legible y un diseño simple hacen que el código contenga, de media, menos errores, y éstos serán más fáciles de detectar y corregir.

Ahora, ¿qué pasa si en algún momento las necesidades del proyecto chocan con nuestro (por ahora) diseño simple? La respuesta es obvia: las necesidades del cliente son el objetivo número uno, y lo demás se tiene que adaptar a éstas. Intentar adaptar las necesidades del cliente al diseño de la aplicación es, en la mayoría de los casos, un error. Si para resolver el nuevo problema hacemos el diseño menos lineal o más complejo, no estamos «haciendo una chapuza porque el cliente no tiene las ideas claras» o porque «no sabe cómo funciona la aplicación»: estamos ayudando a resolver un problema real. Si eso implica hacer una «chapuza» en el código, eso probablemente significa que tenemos que revisar el diseño de nuestra aplicación. No porque lo hayamos hecho mal desde el principio, sino porque hemos descubierto nuevos requisitos, o refinado los que teníamos.

Una conclusión a la que podemos llegar es que la calidad es difícil de conseguir y de medir, y se necesita experiencia y mucho trabajo para obtenerla. Pero la conclusión más importante es que es imposible mejorar la calidad de un proyecto informático aplicando reglas o metodologías. Da igual cuánta experiencia o cuánto conocimiento tenga la persona que las haya formulado, ningún conjunto de reglas o metodologías puede resolver nuestros problemas si las aplicamos sin entender lo que hacemos y en qué contexto son útiles.

La siguiente descripción de un día de trabajo, en un equipo que realiza integración continua, ayudará a ilustrar el proceso y a comprender los elementos necesarios para llevarla a cabo.

Al principio del día lo normal es seleccionar la siguiente tarea más importante a realizar. En base a la reunión de planificación
[Reunión de aproximadamente una hora en la que se decide cuáles serán las tareas a incluir en la siguiente versión de la aplicación.]
y a la reunión diaria
[Breve reunión de seguimiento, diaria, que realiza todo el equipo, donde expone en qué se trabajó el día anterior, en qué se trabajará hoy y si existen impedimentos para llevar a cabo alguna de las tareas en ejecución.]
siempre existe una lista de tareas priorizadas a disposición del equipo de desarrollo, por lo que es muy sencillo saber qué es lo siguiente que debemos hacer. Seleccionamos la tarea en la que debemos trabajar y volvemos a nuestra mesa de trabajo.

El primer paso será actualizar el código fuente del que disponemos con la versión más nueva que exista en el repositorio central. De igual manera, si fuese la primera vez que vamos a trabajar en un proyecto, no tenemos más que descargar una copia limpia del repositorio de código y empezar a hacer nuestro trabajo. A lo largo del día implementaremos la nueva funcionalidad, que debería ser bastante pequeña como para terminarla en una jornada de trabajo y debería incluir una serie de tests que verifiquen que posee el comportamiento deseado. Se puede leer más sobre los tests en otros capítulos del libro, ahora mismo no ahondaremos en el tema porque existen libros enteros sobre TDD y tests unitarios.

Cuando la funcionalidad esté terminada, antes de subir ningún cambio al repositorio, actualizaremos el código fuente con los cambios de nuestros compañeros y nos aseguraremos de que la aplicación sigue construyéndose correctamente y que los tests del proyecto están en verde, es decir que pasan todos sin ningún problema. Si por el contrario aparece algún error lo arreglaremos inmediatamente. Nunca, bajo ningún concepto, se debe subir código al repositorio sin revisar que los tests pasan correctamente y la aplicación se puede construir sin incidencias. Además, es recomendable acceder a la aplicación y revisar rápidamente que todo sigue funcionando adecuadamente, ya que por lo general los tests unitarios no tienen una cobertura del 100%, puesto que ciertos detalles de infraestructura son más sencillos de probar a mano.

Una vez hemos realizado todos los pasos anteriores podemos guardar nuestros cambios en el repositorio de código central, lo que permite que el resto del equipo se actualice y los tengan disponibles en cuestión de segundos.

Aunque el proceso de integración continua comenzó desde el momento en el que empezamos a trabajar en la nueva funcionalidad, el servidor de integración continua comienza a trabajar cuando subimos nuestros cambios al repositorio de código. Dicho sistema se descargará una versión nueva del código fuente con todos los cambios realizados (los nuestros y los de nuestros compañeros), ejecutará los tests y tras hacer la construcción del proyecto lo desplegará en una «réplica» de la máquina de producción. Todo de forma totalmente automatizada. El propio servidor de integración continua podría pasar algunas pruebas extras, como por ejemplo análisis estático de código, análisis de cobertura, o cualquier otro detalle que sería muy tedioso pasar en el proceso de desarrollo porque requiere demasiado tiempo.

También podría haber ocurrido un error. En ese caso el servidor de integración continua nos avisaría con algún mensaje en la consola del mismo o simplemente con el envío de un correo electrónico, que es la opción más común. En ese caso tendremos que inspeccionar cuál ha sido el error y resolverlo para subir una nueva versión corregida. Como el error se genera a los pocos minutos, y no han pasado días ni meses, es muy fácil encontrar dónde está el problema.

La experiencia demuestra que reduce de manera increíble el número de errores en el producto final. Esta es probablemente la mayor ventaja que aporta, porque un producto final con pocos o incluso ningún error es a fin de cuentas el objetivo que todos deseamos como desarrolladores.

Pero no hay que olvidarse de la otra gran ventaja que aporta esta práctica, la transparencia del proceso. Como todos trabajamos utilizando el mismo repositorio de código y la información del servidor de integración es pública, para todo el equipo e incluso a veces para el cliente, se conoce con precisión el estado real del proyecto. No hay que esperar durante meses para saber cómo van las cosas y las reuniones de seguimiento pueden ser cortas y precisas.

Como ventaja añadida cabe destacar la posibilidad de disponer de un servidor de demostración en el que siempre se posee la última versión de la aplicación. De esta manera los clientes pueden probar los últimos cambios día a día y ofrecer información al equipo de desarrollo sin tener que esperar meses.

Ahora ya disponemos de una visión más concreta de lo que es la integración continua, pero nos vendrá bien repasar cuáles son los elementos indispensables para hacerlo correctamente.

Con los pasos descritos hasta el momento ya tendríamos un proceso bastante completo y que a buen seguro mejorará enormemente la calidad de nuestro producto. Pero podemos ir un poco más allá y utilizar el servidor de integración para que haga ciertas tareas relativamente complejas por nosotros.

Por ejemplo, podríamos configurar el servidor para que haga análisis estático de código, de forma que pueda buscar en todo el código bloques sospechosos, bloques duplicados o referencias que no se utilizan, entre otras cosas. Existen gran cantidad de opciones como pueden ser FindBugs o PDM. A simple vista puede parecer algo irrelevante, pero hay que recordar que la complejidad es lo que más ralentiza el proceso de desarrollo, por lo que un código con menor número de líneas y referencias inútiles será más sencillo de leer y entender.

También podríamos incluir tareas que permitan desplegar la aplicación en un servidor, de forma que tendríamos siempre un servidor de demostración con la última versión de nuestro proyecto. Esto es realmente útil cuando tenemos un cliente comprometido, dispuesto a probar todos los nuevos cambios y a dar información al equipo.

Otra operación que podemos automatizar, y que el servidor de integración podría hacer por nosotros, es la realización de pruebas de sistema sobre la aplicación. Imaginemos que estamos desarrollando una aplicación web, podríamos crear tests con alguna herramienta de grabación de la navegación, como por ejemplo Selenium, y lanzarlos con cada construcción que haga el servidor. Es un tipo de prueba que requiere mucho tiempo y no sería viable que se lancen con cada compilación del desarrollador, pero para el servidor de integración no habría ningún problema. Este es solo un ejemplo más de la cantidad de cosas que puede hacer un servidor de integración continua por nosotros, y que nos ayudará a mantener un producto estable y testeado de manera totalmente automática.

Para acabar me gustaría utilizar algunos comentarios escuchados por Martin Fowler cuando habla de integración continua con otros desarrolladores. La primera reacción suele ser algo como «eso no puede funcionar (aquí)» o «hacer eso no cambiará mucho las cosas», pero muchos equipos se dan cuenta de que es más fácil de implementar de lo que parece y pasado un tiempo su reacción cambia a «¿cómo puedes vivir sin eso?». Ahora es tu elección si decides probarlo o no, pero antes de hacerlo piensa en lo poco que tienes que perder y lo mucho que puedes ganar.

Probablemente la forma más fácil de explicar TDD es con un ejemplo a nivel unitario. Supongamos que nuestra aplicación necesita convertir millas a kilómetros; empezamos con una prueba:

El motivo más importante
[Para mí el más importante, seguro que otros discreparán.]
para desarrollar dirigido por pruebas es el énfasis en la función de nuestro código y en su idoneidad para ponerlo a prueba y por lo tanto usarlo. Este énfasis nos obliga a preguntarnos cada vez que vamos a añadir código de explotación: ¿es esto lo que necesito? ¿hace falta ahora?; ayudándonos a escribir exclusivamente lo que necesitamos y a mantener el tamaño y la complejidad del código al mínimo necesario.

Si bien TDD no exime de buscar y dirigir el diseño deliberadamente, escribir código que, desde el primer momento, es fácil de probar favorece una cierta simplicidad y, definitivamente, evidencia el acoplamiento, guiándonos hacia el cuidado de la colaboración entre las unidades. En particular, la inyección de dependencias y la separación entre sus interfaces y las implementaciones, emergen de forma natural, dado que facilitan las pruebas automatizadas.

Los proyectos que se desarrollan dirigidos por pruebas cuentan en todo momento con una batería de pruebas al día, que documenta la intención de cada unidad del software, de combinaciones de unidades y del software en su totalidad. Además, las pruebas, si bien no la garantizan, dan una buena indicación de la corrección del software; lo que reduce el miedo a romper algo, y lo sustituye por un hábito diligente de refactorizar con frecuencia y mejorar el diseño progresivamente.

Hasta ahora nos hemos centrado en las pruebas unitarias; no obstante, si somos consecuentes con los principios que hemos visto —guiarnos manteniendo el enfoque en los objetivos del software, documentar y verificar—, deberemos considerar fundamental guiar el desarrollo de cada parte de la funcionalidad mediante una prueba que la ejercite en su conjunto; lo ideal será que todas las pruebas funcionales verifiquen el conjunto del software, en un entorno similar al de explotación, o incluso en el entorno de explotación en sí. En la práctica suele haber muchos obstáculos, por ejemplo, puede que sea demasiado costoso llevar a cabo de verdad ciertas acciones destructivas, que no haya suficientes recursos, o que se hayan impuesto decisiones arquitectónicas que dificulten las pruebas; sin embargo, eso no significa que tengamos que claudicar completamente; a menudo, lograremos las mejoras más importantes en el software y en la organización en la que se crea cuestionando las limitaciones.

El mantenimiento de la batería de pruebas, que crece con la aplicación, requiere una inversión de esfuerzo constante; hacer que cada prueba verifique únicamente un aspecto de la aplicación nos ayudará a mantener este esfuerzo manejable y además las hará más fáciles de entender, y por lo tanto más eficientes. Idealmente, el cambio de un detalle del funcionamiento de nuestra aplicación debería afectar exclusivamente a una prueba que sólo verifica ese detalle, o, dicho de otra manera:

La batería de pruebas es la documentación de la funcionalidad de nuestro código. Una documentación que se mantiene al día, porque va creciendo con cada cambio y es ejercitada, es decir, ejecutamos las pruebas, al menos con cada envío de los cambios al repositorio.

Trabajar dirigido por pruebas significa mantener siempre el correcto funcionamiento del sistema; idealmente la última versión en el repositorio común deberá estar en todo momento lista para ponerla en explotación, y las pruebas satisfechas en todo momento
[De hecho, algunos equipos hacen exactamente eso, ponen cada versión que satisface la batería completa automáticamente en explotación.]
, con lo que la documentación proporcionada por las pruebas estará siempre al día. Para lograrlo, deberemos comprobar la satisfacción de las pruebas antes de enviar cualquier cambio al repositorio común; además, muchos equipos se ayudan de un sistema de integración continua que verifica automáticamente la batería cada vez que se detecta un cambio en el repositorio.

A medida que crece la aplicación, el tiempo que requiere la batería completa tiende a aumentar, lo que incrementa el coste del desarrollo y motiva a los desarrolladores a no siempre satisfacer la batería completa o a espaciar los envíos de cambios al repositorio común; ambos efectos muy perniciosos. Para mantener viable la programación dirigida por pruebas, debemos esforzarnos en mantener reducido este tiempo; la manera de lograrlo va más allá de un artículo introductorio, pero incluye la selección y el ajuste de la tecnología empleada para los distintos elementos de la batería, la ejecución en paralelo e incluso la partición de la aplicación en sí o cualquier ajuste que la haga más rápida.
[Otra forma de reducir el tiempo es transigiendo en alguna medida, es decir, no cumpliendo en ocasiones todo lo que describimos en este artículo.]

Otro problema relacionado con el coste de la batería son los fallos intermitentes, que necesitarán un esfuerzo importante de mantenimiento; hemos de invertir el esfuerzo necesario para entender la raíz de cada fallo y resolverlo. Las fuentes típicas de fallos intermitentes son los aspectos no deterministas del software; por ejemplo, cuando lo que verificamos es de naturaleza asíncrona, necesitamos controlar el estado de la aplicación mediante puntos de sincronización. Algunas condiciones son imposibles de verificar per se, como la ausencia de comportamiento; en estos casos a menudo la solución pasa por alterar la aplicación desvelando su estado lo suficiente como para que las pruebas puedan sincronizarse con la aplicación y sepan cuándo debería haber tenido lugar el evento que estemos verificando. También suelen causar fallos intermitentes las dependencias de elementos fuera del control de la prueba, como el reloj del sistema; y su solución pasa normalmente por la inclusión y el control de dicho elemento desde la prueba, por ejemplo, alterando la percepción del tiempo de la aplicación mediante un proxy controlable desde las pruebas.

El desarrollo dirigido por pruebas nos ayuda a construir aplicaciones donde aquello que nos motiva a escribir el software guía cada línea de código, evitando a cada nivel desperdiciar nuestros esfuerzos en desarrollar funcionalidad que no sea exactamente la que necesitamos, o que sea simplemente innecesaria. La guía de las pruebas, combinada con el diseño continuo, hace posible un estilo de desarrollo orgánico, en el que el equipo evoluciona la aplicación, a medida que mejora su conocimiento de los requisitos del dominio y de la implementación ideal para resolverlos. Además, la utilización de pruebas desde el primer momento, desvela el acoplamiento y nos incita a descomponer el código en unidades cohesivas con depencias claramente identificadas.

Si bien no hay un concenso absoluto en la idoneidad del desarrollo guiado por pruebas, muchos equipos lo usan, particularmente para aplicaciones comerciales y en lenguajes orientados a objetos. Nuestra opinión es que, además de dar sentido y ritmo a cada actividad del desarrollo, lo hace más divertido, porque da al desarrollador más libertad para mejorar y acrecentar el software.