Acerca de este libro

Este libro nació un poco sin querer. O, al menos, no empezó siendo un libro, sino una colección de unos cuantos artículos en el blog The Talking Bit.

Hace varios años que me acostumbré a escribir las cosas que aprendo o sobre las que intento profundizar. Escribir para uno mismo puede ser difícil porque lo aplazas, o lo haces de una manera desorganizada y acabas perdiendo las cosas. O acabas dejándolo.

Por eso, un buen día decidí hacer un blog.

Para mí un blog tiene varias ventajas:

• La primera es que tienes todas la notas en un sólo sitio.
• Ese sitio está en la nube, accesible desde cualquier dispositivo, así que cuando necesitas consultar algo ahí está.
• Una vez que escribes, te puedes quitar el problema de la cabeza.
• Como cabe la remota posibilidad de que alguien más que tú lo lea, tienes más cuidado al escribir. Te diriges a una persona diferente a ti y procuras no dar demasiadas cosas por sentadas.
• También procuras tener más rigor, y no es la primera vez que empiezo un artículo con una idea y acabo defendiendo la contraria porque al analizarla me doy cuenta de que mi planteamiento inicial era el equivocado.
• Eso también hace que te sientas más comprometido a escribir cosas con cierta frecuencia.

En general, no hay nada mejor para aprender algo que intentar enseñar a otros, aunque los “otros” sean una entidad más o menos abstracta.

El caso es que un buen día me di cuenta de que había escrito un puñado de artículos sobre testing en el blog. Al fin y al cabo es un tema que siempre me ha llamado la atención y que, profesionalmente, me interesa muchísimo.

Entonces se me ocurrió pensar en que podría hacerse un libro con ellos. Por un lado, es verdad que los artículos están disponibles en la web, pero también lo es que muchas personas prefieren tenerlo todo en un mismo lugar.

Como conocía LeanPub pensé en hacer la prueba de crear un prototipo de libro, por ver si tenía entidad suficiente. Resultó que sí: salieron más de trescientas páginas de prosa y código.

Obviamente, una colección de artículos escritos a lo largo de casi tres años no se convierte automáticamente en un libro. Hay que hacer algunos arreglos, como intentar eliminar las referencias al blog o a cuestiones temporales que serían incomprensibles en el libro. Por otro lado, los artículos no tenían un plan, por lo que fue necesario darles un poco de orden y de unidad.

La progresión de artículos dejaba algunas lagunas, como algún tipo de proyecto sencillo para introducir a los potenciales lectores al testing en general y a la metodología TDD en particular. Por esa razón, el libro incluye algunos elementos que no están en el blog.

Además, hubo algún artículo que tuve que cambiar porque el código ni siquiera estaba en PHP.

Finalmente, quería incluir algunos detalles más básicos de instalación y configuración, en forma de apéndices.

Y aquí tienes el resultado.

Algunas limitaciones del libro

Dado que el origen del libro ha sido un poco caótico, es posible que notes que falta una cierta sistemática, un hilo o una organización. He intentando que haya bastantes temas cubiertos, pero soy consciente de que algunos han quedado cojos. Por otro lado, hay cuestiones que aparecen de forma repetida.

El libro no es, ni pretende ser, un curso o un manual definitivo. Tómalo como una recopilación de ideas acerca de cómo testear y, particularmente, sobre cómo practicar Test Driven Development en PHP.

A partir de algunas de las lagunas más significativas quizá me anime a desarrollar algún volumen más. Para empezar, uno sobre el testing de clases con dependencias, es decir con test doubles, y otro sobre Behavior Driven Development, también orientados a PHP. El tema de los test doubles es interesante porque genera un montón de dudas y afecta mucho a la calidad de los tests y, aunque en el libro se toca, quizá falta profundidad y entrar en detalle.

Como usar el libro

Pues como quieras. No hay un orden más o menos recomendable. He intentado agrupar los aspectos más teóricos y de definición de términos en los primeros capítulos.

En la Introducción: Del ojímetro al tdd encontrarás un resumen de prácticamente toda la teoría y terminología básica de testing.

Testing desde cero es un capítulo que extiende la introducción, siendo algo más detallado, en el que se explican todos los aspectos fundamentales del proceso de test.

Testing en contexto busca explicar los distintos niveles de testing y qué información nos proporcionan.

Psicología del testing es un capítulo en el que especulo sobre las dificultades técnicas y no técnicas de testear. Lo cierto es que ser consciente de estos problemas, me ha ayudado mucho a situar el testing en mi práctica diaria.

A partir de ahi, empiezan los capítulos más orientados a la práctica con ejemplos de código y pequeños proyectos, aunque con alguna cuestión más teórica intercalada:

Primer test explica cómo testear una clase desde cero. Es el capítulo que deberías leer si no has hecho nunca tests o has empezado, pero no lo tienes nada claro todavía.

Un ejercicio para aprender TDD es un ejercicio muy sencillo, pero potente que nos ayuda a introducir y desarrollar la metodología Test Driven Development.

Desarrollar un algoritmo paso a paso con TDD: Luhn Test kata la Luhn Test kata es un ejercicio de TDD muy bonito, algo más complejo que el del artículo anterior aunque basado en el mismo tipo de problema, y que te servirá para afianzar la metodología y descubrir cómo testear por partes algoritmos más complejos.

Clean testing discute algunos aspectos sobre cómo escribir tests que sean más expresivos y útiles.

Test doubles (1) y Test doubles (2) Principios de diseño estudian los distintos tipos de dobles de tests, sus aplicaciones y cómo se relacionan con los principios de diseño.

Test doubles(3) un proyecto desde cero es, como indica su título un proyecto de TDD usando doubles.

Resolver problemas con baby-steps es un capítulo que vuelve a incidir sobre la base de la metodología TDD.

Usar el code coverage para mejorar los tests busca reflexionar sobre la utilidad de la medida de la cobertura de código para mejorar nuestra batería de tests.

Testeando lo impredecible se trata de un ejercicio teórico y práctico sobre cómo testear situaciones no determinísticas, como el azar, en el que desarrollamos un generador de contraseñas. Además, es un buen ejercicio sobre el uso de los test doubles. Es un proyecto en el que también se puede ver cómo trabajar con dependencias y dobles.

TDD en PHP. Un ejemplo con colecciones (1 a 5) es un proyecto para desarrollar una clase Collection usando la metodología TDD y que sirve como resumen de todo, o casi todo, el contenido del libro.

Lo ideal sería que te animases a realizar los ejemplos por tu cuenta y en tu propio estilo a medida que lees el libro.

Finalmente, una serie de apéndices aportan información de carácter más práctico sobre algunos de los frameworks de testing y TDD disponibles para PHP, así como un dojo, un proyecto básico PHP/Symfony dockerizado que puedes usar para practicar tanto los ejemplos del libro como cualquier otro que se te ocurra.

Gracias

Posiblemente este proyecto nació, aunque entonces no lo sabía, en un meetup de PHPVigo en el que hice una charla introduciendo el tema del testing y que, de hecho, es más o menos el primer capítulo de introducción. Todo lo demás, el blog y el propio libro son, por así decir, extensiones de esa charla.

Así que gracias a la gente de PHPVigo, en particular Sergio Carracedo, Félix Gómez y Rolando Caldas, por haber confiado en un perfecto desconocido aquel día de hace ya un par de años.

Hablando de confiar en desconocidos, poco después de esa charla me vine a trabajar a Barcelona. Gracias a Ricard Clau por hacer que eso fuera posible. Y gracias especiales a Raúl Araya por un montón de cosas, que mejoraron mucho mi vida aquí.

Aprendí muchísimo en los coding dojo de la Software Crafters en donde, además, me sentí muy acogido. No os menciono en detalle porque seguro que me olvido de alguien y sería muy injusto.

Gracias a Javi y Rafa, de CodelyTV, por apoyar el libro como lo están haciendo.

Gracias a Alexey Pyltsyn, que está preparando la versión en ruso del libro.

Y, por supuesto, gracias a todo el equipo de HolaluzEng, por haberme hecho sentir en casa desde el primer día, por ayudarme a crecer profesionalmente y por estar ahí siempre que lo he necesitado.

Introducción: Del ojímetro al tdd

Porque todos tenemos spaghetti apestando en el armario y en algún momento hay que limpiarlo.

Cuando empiezas a programar en PHP (o en cualquier otro lenguaje, para el caso) sin tener una formación sistemática muchas veces te guías por ocurrencias: abres un editor y comienzas a picar código como si te fuera la vida en ello. Al final del día obtienes una gran bola de lodo que, más o menos, funciona y que a ti te parece la versión informática de la Gioconda. O algo así.

Claro que, al día siguiente, algo falla. Siempre falla. Vuelves a la gran bola de lodo, te pringas, y arreglas lo que fallaba.

El problema es cuando falla unos días después, y ya no tienes ni idea de qué iba dónde y cómo funcionaba la cosa, así que añades código hasta que la aplicación deja de gotear.

Y el ciclo se repite.

¿Y cómo sabes que la cosa funciona? Bueno… Pues viendo que subido a producción “No falla” (hasta que lo hace). Lo que viene siendo un “testing manual” o, con un lenguaje más técnico, testing a ojímetro.

Todos y todas tenemos código basura en alguna parte. Da igual los años de experiencia: las prisas, un análisis descuidado del problema, el enrocarnos en una solución y otros muchos motivos hacen que hagamos código que, visto en retrospectiva, nos parece una basura.

Y eso está bien. Lo importante es tener la capacidad de aprender a partir de ahí.

Ocurre lo mismo con el testing. Es posible que hayas pasado años escribiendo código que funciona en producción sin haber escrito un sólo test que lo cubra. Simplemente ocurre que ahora quieres tener más garantías, por ti, por tu equipo y por tu proyecto.

Entonces descubres los tests

Mi primer contacto con las suites de tests fue con SimpleTest, indirectamente a través de la suite de tests de CakePHP.

No puedo decir que fuese una epifanía. Al principio no entendía ni torta, con todo el rollo de las aserciones y los mocks. Al fin y al cabo, testear ActiveRecord no es precisamente ni lo más fácil para uno que empieza ni lo más recomendable, y en un framework MVC es casi inevitable. Incluso algo tan simple como la idea de ejecutar un trozo de código dentro de otro código (el test) resultaba extraña.

Sencillamente dicho: un test no es más que un programa simple que comprueba si el resultado de otro programa (o unidad de software, ya sea una función o un método de un objeto) devuelve el resultado que se espera tras pasarle unos parámetros.

Al principio haces post-tests: tienes un montón de código escrito y te has dado cuenta de que es necesario saber si cada unidad funciona como esperas en los casos que debería manejar.

Los post-tests no son perfectos pero son útiles y son el primer paso para poner un poco de orden en lo que escribes. Gracias a esos tests empiezas a manejar el refactoring, aunque no lo llames así todavía.

Michael Feathers, que de refactoring y legacy sabe un rato, llama a estos tests “Tests de caracterización”. Son los que se hacen para describir y/o descubrir el comportamiento actual de un módulo de software legacy y como primer paso para reescribirlo. Con este test tendríamos una red de seguridad para ir haciendo los cambios necesarios.

Pero en realidad, estoy siendo demasiado impreciso. Es necesario parar un momento y ser un poco más sistemático.

Control de calidad

El control de calidad del software engloba un montón de tipos de pruebas, que podemos agrupar en dos familias principales:

Pruebas funcionales: que tratan de medir lo que hace el software en base a unas especificaciones previas. Es decir: las pruebas funcionales nos sirven para asegurar que el software hace aquello que queremos que haga.

Pruebas no funcionales: que tratan de medir cómo lo hace a través de métricas más genéricas como el rendimiento, la capacidad de carga, la velocidad, la capacidad de recuperación, etc.

En realidad, usamos muy alegremente la palabra test, con sentidos más genéricos o más restringidos, lo que puede llevar a cierta confusión.

Muchas veces, cuando hablamos de tests, nos estamos refiriendo únicamente a un subconjunto de los variados tipos de pruebas funcionales y, precisamente, ese es el contenido principal de este libro.

Muchos programadores hemos empezado con la metodología de “Ojímetro testing(tm)”, es decir: observar el output del programa, con frecuencia recargando una página en un navegador.

El hecho de simplemente observar el output de nuestro programa no suele ser suficiente para constituir una prueba funcional válida.

Para empezar, no estamos definiendo de forma precisa, objetiva y reproducible (operacional) lo que queremos observar.

Lo que vemos al recargar una página es el resultado de un conjunto de operaciones, y sólo una de ellas es la pieza concreta de código de la cual queremos saber si funciona. Por lo tanto, no tenemos garantía de que el resultado se produce por las razones que pensamos, es decir, por efecto del algoritmo que hemos escrito, sino que podría haber efectos colaterales de diversos componentes del programa.

Digámoslo honestamente: no tenemos ni idea de lo que estamos midiendo.

Necesitamos introducir un poco de método científico en nuestro trabajo. Como he señalado antes, los tests no son más que programas sencillos que comparan el resultado generado por nuestra unidad de software con el resultado que esperamos obtener dadas unas condiciones iniciales. Los tests nos permiten definir con precisión las condiciones bajo las que ejecutamos la prueba, las acciones que se van a ejecutar y los resultados que deberíamos obtener, todo de una manera replicable.

Lo que viene a continuación es prácticamente un resumen del libro entero. En los siguientes capítulos verás las ideas más desarrolladas, así como ejemplos de código.

Tests funcionales

Existen varios tipos de tests funcionales y aquí me voy a centrar en algunos. Eso sí, no sin advertir que las fronteras, a veces son un poco difusas:

Tests unitarios son los que evalúan lo que hace una unidad de software en aislamiento, es decir, sin que otras unidades intervengan realmente. Una unidad de software es un término que normalmente designa una función, una clase o, más bien, un método de una clase.

En último término es frecuente tener dependencias de otras unidades de software, por lo que en situación de tests tenemos que usar “dobles” en su lugar, de modo que podamos mantener bajo control sus efectos.

Por poner un ejemplo un poco bruto: si tenemos una clase que utiliza un Logger para comunicar el resultado de una operación y observamos que no se añade nada al log, tenemos que poder diferenciar si el problema es de la clase o del Logger. El Logger tiene diversos motivos para fallar que no tienen nada que ver con la clase que estamos probando, así que necesitamos un Logger que no falle, preferiblemente uno que no haga nada de nada, neutralizando así sus efectos colaterales. Ese falso Logger es el que usamos en la situación de test.

Hablaremos de ello dentro de un rato.

De este modo, podemos afirmar que el resultado devuelto por la unidad es producido por el algoritmo que ésta contiene y no por otros agentes.

Tests de integración: evalúan lo que hacen las unidades de software en interacción. Es posible que nuestras unidades funcionen bien por separado, pero ¿qué ocurre si las juntamos? Los tests de integración dan respuesta a esa pregunta.

Volviendo al ejemplo de antes, si tanto la clase probada como el Logger funcionan bien por separado, probamos a hacerlas funcionar juntas, para ver si aparecen fallos en su comunicación.

Tests de caracterización: ya los mencionamos antes. Los tests de caracterización son tests que se escriben para tratar de describir el comportamiento de una unidad de software ya escrita. En muchos casos llamar unidad de software a cierto código legacy puede ser un poco impreciso, lo correcto sería denominarlo “bola de lodo”, ya que seguramente se trata de código muy acoplado y desestructurado.

Tests de regresión: son tests que detectan los efectos negativos de los cambios que realizamos en el software. Es decir, si estos tests fallan es que hemos tocado algo que no debíamos.

Hasta cierto punto podríamos decir que todo test, una vez que ha pasado, se convierte en un test de regresión a partir del momento en que comenzamos a modificar un software.

Tests de aceptación: responden a la pregunta de si la funcionalidad está implementada en términos de los interesados en el software, también llamados stakeholders. Los tests de aceptación son, también, tests de integración.

Anatomía de un test

En general, los tests tienen una estructura muy simple. De hecho, los tests deberían ser siempre muy simples. Esta estructura tendría tres grandes partes:

Dado…

En esta parte definimos el escenario del test, preparando las condiciones en las que vamos a probar la funcionalidad.

Cuando…

Es la ejecución de la unidad de software en la que estamos interesados (o subject under test).

Entonces…

Es cuando comparamos el resultado obtenido con el esperado, habitualmente a través de Aserciones, es decir, condiciones que debería cumplir el resultado para ser aceptado. Por ejemplo, ser igual a, ser distinto, no estar vacío, etc…

Manejo de las dependencias

En POO es habitual que una clase utilice colaboradores para realizar un comportamiento, lo que nos plantea la pregunta de cómo manejar esta situación si los tests deberían probarse en aislamiento a fin de garantizar que evaluamos el comportamiento de esa unidad de software concreta.

Por otra parte, algunas de esas dependencias pueden ser bastante complicadas de obtener en una situación de desarrollo, como pueden ser el acceso a servicios web, servidores de correo, etc. Por no hablar, de la posibilidad de que haya fallos, de las distintas respuestas posibles, de la lentitud, del proceso de instanciación, de la configuración y un largo etcétera de dificultades.

Para eso, están los dobles o test doubles.

Se trata de objetos creados para reemplazar las dependencias en situación de test. Son éstos:

Dummies: son objetos que no hacen nada más que implementar una interfaz, pero sin añadir comportamiento. Los usamos porque necesitamos pasar la dependencia para poder instancias el objeto bajo test.

Por cierto, los test doubles, en general, ponen en valor el principio de Inversión de Dependencias. Si nuestro objeto bajo test depende de una interfaz, crear un Dummy es trivial. Si la dependencia es de una implementación completa la cosa puede complicarse, porque tendrías que extender la clase y neutralizar todo su comportamiento.

Así que suele ser mejor estrategia, en ese caso, extraer la interfaz y crear un Dummy. Y esto es bueno, porque te ayuda a reconsiderar tu diseño.

Stubs: los dummies son útiles, pero muchas veces necesitamos que la dependencia nos de una respuesta. Los Stubs son como los dummies en el sentido de que implementan una interfaz, pero también devuelven respuestas fijas y conocidas cuando los llamamos.

Por ejemplo, podemos tener una dependencia de una clase Mailer que devuelve true cuando un mensaje ha sido enviado con éxito. Para testear nuestra clase consumidora de Mailer, podemos tener un MailerStub que devuelve true (o false) sin tener que enviar ningún mensaje real, permitiéndonos hacer el test sin necesidad de configurar servidor de correo, ni importunar a media empresa con un correo de pruebas que se te escapa, ni tener conexión de red, si me apuras.

Así que podríamos decir que los Stubs tienen un poco de comportamiento superficial a medida para los fines del test.

Spies: los spies son test doubles capaces de recoger información sobre cómo son usados y con ellos empezamos a movernos en aguas un poco cenagosas. Por ejemplo, los spies podrían registrar el número de veces que los hemos llamado. De este modo, al final del test obtenemos esa información y la comparamos con el número de llamadas esperado.

El problema es que este tipo estrategias de test implican un acoplamiento del test a la implementación, lo que genera un test frágil. Y esto merece una explicación:

Los test funcionales deben ser de “caja negra”: conocemos las entradas (inputs) y las salidas (outputs) pero no deberíamos tener ni idea del proceso que se sigue dentro de ellas. Sí, ya lo sé, lo hemos escrito nosotros, pero se trata de actuar como si no tuviésemos acceso al código.

Por tanto, un test basado en cómo o cuándo se llama a un método en un colaborador está irremediablemente ligado a esa implementación. Si se cambia la implementación, por ejemplo porque se puede hacer lo mismo con menos llamadas u otras distintas, el test fallaría incluso aunque el output fuese correcto. Por eso decimos que es un test frágil: porque puede fallar por motivos por los que no debería hacerlo.

Nuestros siguientes dobles, tienen el mismo problema, pero agravado:

Mocks: por desgracia el término mock se usa mucho para referirse a todo tipo de test double, pero en realidad es un tipo particular y no demasiado conveniente. Un Mock es un Spy con expectativas, es decir, los Mocks esperan específicamente ser llamados de cierta manera, con ciertos parámetros o con cierta frecuencia, de modo que ellos mismos realizan la prueba o aserción.

De nuevo, tenemos el problema de acoplamiento a la implementación, pero agravado, ya que el Mock puede comprobar que lo has llamado con tal o cual argumento y no con otro, o que has llamado antes a tal método o a tal otro, etc. Si con un Spy el test es frágil, con Mock puede ser un “mírame y no me toques”.

Al final, el test reproduce prácticamente el algoritmo que estás probando por lo que no nos vale de mucho. En el momento en que hagas un cambio en la implementación, el test fallará.

El uso de spies y mocks en los tests puede revelar problemas de diseño. Por ejemplo, podrían indicar que una unidad de software tiene un exceso de dependencias o de responsabilidades. O tal vez, te está diciendo que deberías encapsular alguna funcionalidad que estás pidiendo a las dependencias.

Fake: El último miembro de la familia de los Tests Doubles es el Fake, un impostor. En realidad es una implementación de la dependencia creada a medida para la situación de test.

Es decir, tú quieres probar una unidad de software que tiene una dependencia complicada, como puede ser una base de datos o el sistema de archivos. Pues tú vas y creas una implementación de esa base de datos “pero más sencilla” para poder testar tu clase. Lo malo, es que el Fake en sí también necesita tests, porque no sólo es la implementación tonta de la interfaz (como un Dummy) o de un comportamiento básico (como un Stub), sino que es una implementación funcional concreta y completa, que hasta podría llegar a usarse en producción.

Los ejemplos clásicos son las implementaciones en memoria de repositorios, bases de datos, sistemas de archivos, etc.

Robert C. Martin explica toda la problemática de los test doubles en este artículo bastante socrático.

Cuándo toca hacer tests

A primera vista puede parece que el mejor momento de hacer tests es una vez que hayamos creado nuestras unidades de software y así comprobar que funcionan bien.

Pues no. Aunque siempre es mejor tener tests a posteriori que no tener ninguno, hay un momento aún mejor: escribir los tests antes de escribir el código.

Si lo piensas bien es muy lógico: antes de escribir el código tienes unas especificaciones, tienes un problema que resolver y unos datos para hacerlo. Los tests pueden entenderse como una manera formal de expresar esas especificaciones. Luego escribes el código con el objetivo de que los tests pasen.

Psicológicamente hablando, los tests creados después del código pueden resultar más difíciles de hacer por la sensación de “trabajo terminado” e incluso el miedo a que aparezca algún fallo inesperado. Por el contrario, los tests previos proporcionan una guía de trabajo y un refuerzo positivo al ir marcando nuestros éxitos a medida que vamos escribiendo el código.

Llevada al extremo, esa idea se denomina Test Driven Development o TDD.

Test Driven Development

El Test Driven Development es un modelo o disciplina de desarrollo que se basa en la creación de tests previamente a la escritura de código pero siguiendo un bucle de cambios mínimos y reescritura.

Me explico:

Al principio, no hay nada más que la especificación sobre lo que vas a construir. Tal vez decidas que lo primero que necesitas es una cierta clase.

Y lo primero que haces no es escribir la clase, sino un test para probar la clase. Es la primera ley de TDD, tal cual las recopila Robert C. Martin:

No escribirás código de producción sin antes escribir un test que falle.

Hemos dicho que TDD se basa en un bucle de “cambios mínimos”, así que el test mínimo será que exista la clase. Por lo tanto, te vas a tu IDE y creas un test que requiere la clase que vas a probar. Bueno. Si quieres, puedes instanciarla, que tampoco vamos a ser tan estrictos.

Ahora ejecutas el test.

– ¡Pero si va a fallar, alma de dios! Primero tendremos que definir la clase aunque esté vacía, ¿no?

Pues no. Primero escribes el test suficiente para fallar. El test tiene que fallar. Es la segunda ley de TDD:

No escribirás más de un test unitario suficiente para fallar (y no compilar es fallar)

Bueno, en PHP lo de no compilar como que no, pero podemos asumir que errores del tipo “class not found” equivalen a esto. En general, cualquier error nos vale.

La filosofía es la siguiente: cada test que falla te dice qué es lo que tienes que hacer a continuación. No tienes que poner nada nuevo hasta que no tengas un test que te pida hacerlo, ni siquiera el esqueleto de la nueva clase. Si la clase no se encuentra, es que tienes que crearla; si no tiene un método, es que tienes que crearlo; si el método no hace nada con el parámetro que recibe, es que tienes que escribir código que lo maneje…

Así que lo que haces ahora es crear un archivo para la nueva clase y escribes lo mínimo para que el test pueda cargarla e instanciarla. Y esa es la tercera ley:

No escribirás más código del necesario para hacer pasar el test.

Bien. Una vez has conseguido pasar este primer test hay que seguir un poco más. Tal vez tu clase va a tener un método público por el que vamos a empezar a trabajar y que debería devolver cierto valor.

Pues nuestro siguiente paso consiste en crear un test que simplemente intenta utilizar ese método. Y ejecutamos los tests.

Y al ver que falla, escribimos el método aunque no haga nada.

Y luego escribimos otro test que espera que el susodicho método devuelva cierto valor. Y como falla, vamos a la clase y hacemos que el método devuelva el valor esperado (sí, como has leído) para que pase el test.

– ¡Me estás tomando el pelo!

No. No te estoy tomando el pelo. Lo que ocurre es con cada pequeña iteración “test mínimo-código mínimo para que pase” estamos modelando nuestra clase. Cada nuevo test construye sobre lo existente y avanza un poco más hacia la implementación deseada.

Lo cierto es que si escribimos un nuevo test y vemos que no falla no nos dice nada útil, ya que no prueba nada que no hayamos probado ya. O bien nos indica que es el test el que falla.

Nuestro siguiente test tal vez tenga que probar la condición de que si instanciamos la clase con cierto parámetro el valor devuelto por el método será otro.

Así que tendremos que reescribir ese método para tener en cuenta esa circunstancia. Ahí empezarás a sentirte mejor porque vas a escribir comportamiento, pero no te aceleres: ve paso por paso. Aunque este ciclo parece un coñazo, en realidad cada iteración es muy rápida. Algunas herramientas, como PHPSpec, incluyen un generador de código que automatiza algunos de estos pasos.

TDD es una disciplina. No digo que sea fácil conseguirla, incluso al principio suena un poco descabellada. Si consigues convertirla en un hábito mental tienes una herramienta muy poderosa en tus manos.

A partir de cierto momento, comienzas a introducir el refactoring. Cuando el código alcanza cierta complejidad, comienzas a plantearte soluciones más generales y debes comenzar a ajustar la arquitectura. Creas métodos privados para resolver casos específicos, cláusulas de guarda, etc, etc. Los tests que ya has hecho te protegen para realizar esos cambios, aunque en algún momento puede que decidas refactorizar los test porque la solución ha avanzado hacia otro planteamiento diferente.

TDD favorece lo que se llama diseño emergente: al ir añadiendo tests, que evalúan que nuestro diseño cumpla ciertas especificaciones, van definiéndose diferentes aspectos del problema y nos impulsa hacia soluciones cada vez más generales.

La consecuencia de seguir la disciplina TDD es que tu código está automáticamente documentado y respaldado por tests en todo momento. No hay que esperar. Si un cambio introduce un problema, habrá un test que falle. El código estará listo para funcionar casi en el mismo momento de escribirlo. ¿Qué no te gusta la arquitectura y podrías hacerlo mejor? Los tests te protegen de los cambios porque cuando rompas algo lo sabrás de inmediato.

Las consecuencias en la calidad de tu código también se notarán. Para escribir tests de esta manera tienes que crear código desacoplado. Seguir los principios SOLID como guía en la toma de decisiones es lo que te va a permitir lograr justamente eso.

Es posible que, al principio, no te veas capaz de llegar a este nivel de trabajo y micro-progresión y tu práctica sea más desorganizada. Pero no te preocupes, avanza hacia ese objetivo. Un paso cada vez.

Qué incluir en los tests y qué no

Depende.

No hay una regla de oro, aunque puedes encontrar en Internet montones de reglas más o menos prácticas.

Yo más bien diría que hay que aprender a priorizar los tests necesarios en cada caso y momento particular.

Cosas más o menos claras

No se hacen tests de métodos o propiedades privadas. Los tests se hacen sobre la API pública de las clases.

La complejidad ciclomática de una unidad de software (la cantidad de cursos posibles que puede seguir el código) nos indicaría un mínimo de tests necesarios para cubrirla con garantía.

El dominio/negocio debería tener la máxima cobertura de tests que puedas, dado que constituye el core de tu aplicación.

Hay código trivial, como getters/setters, controllers si están bien realmente bien hechos, y otras partes del código que puedes no testear o diferir su testing, pero nunca se sabe, porque un getter podría llegar a dejar de ser trivial.

Haz tests cuando tengas que hacer algún cambio (test de caracterización) o corregir errores (test de regresión, que evidencie el error).

Testear librerías de terceros que ya están bien testeadas no merece la pena. Más bien nos interesa evaluar la interacción de nuestro código con ellas. Se supone que Doctrine va a devolver esos datos que le pides, el problema estaría en cómo se los pides o qué haces con ellos, y eso podría necesitar un test.

Code Coverage

El code coverage nos da una medida de las líneas de código que se han ejecutado en un test o batería de tests. Un Code Coverage de 100% nos dice que los tests han recorrido todos los caminos posibles de la unidad evaluada.

Sin embargo, no debe tomarse como objetivo. Muchas clases tienen métodos triviales cuyo testing tal vez nos convenga posponer. En un proyecto mediano es difícil llegar a ese 100%, lo cual no invalida que intentes conseguir el máximo posible, pero usando la cabeza.

El code coverage por sí mismo no dice mucho sobre la calidad de los tests. Éstos pueden cubrir el 100% del código y ser malos o frágiles.

El Code Coverage es una buena herramienta para decidir qué testear, ya que podemos identificar recorridos de la unidad que han quedado sin pruebas y que, por tanto, podrían mantener escondidos problemas.

Y esto es casi todo

Esta introducción ha quedado casi como un resumen del libro. No está mal. A partir de aquí, los diferentes capítulos te mostrarán una visión más detallada de cada aspecto del testing, sobre todo desde un punto de vista del test driven development.

Habrá capítulos más teóricos y otros más orientados a la práctica. Cosas con las que estarás de acuerdo y cosas con las que no. Podemos discutirlas cuando quieras en el blog o en twitter @talkingbit1.

Gracias por seguir leyendo.

Testing desde cero

En realidad, ya sabes testear software. Lo haces a todas horas. En último término, testear software es comprobar que un programa funciona como se desea que funcione y hace aquello que esperamos que haga. Y esto es algo que sucede cada vez que escribimos una pieza de código.

Ahora bien, esta forma de testeo manual o natural no resulta ni lo suficientemente sólida ni rigurosa como para permitirnos argumentar que nuestro código funciona correctamente. El mismo código trasladado a otro entorno podría funcionar mal, o generar errores porque no hemos tenido en cuenta controlar las diferencias entre nuestro espacio de desarrollo y el de producción.

Hace falta, por tanto, una metodología sistemática para verificar el funcionamiento de un programa. Esa metodología comprende una serie de conceptos, actividades y técnicas que agrupamos bajo la denominación de software testing.

Qué es software testing

Software testing define un conjunto de actividades y técnicas que se utilizan para comprobar o certificar que un software desarrollado cumple las especificaciones de funcionamiento establecidas. En otras palabras: testear un software es asegurarse de que hace lo que queremos o esperamos que haga.

Por supuesto, esta definición es bastante vaga y deberíamos matizar algunas cosas.

Cuando hablamos de especificaciones del software nos estamos refiriendo a cuál es el comportamiento que queremos que tenga o lo que necesitamos que haga. Podemos definir estas especificaciones de varias formas, más o menos precisas: esperando valores específicos, recurriendo a ejemplos, midiendo ciertos parámetros, analizando propiedades, etc.

Un aspecto del funcionamiento del software aparte de su utilidad y que nos puede interesar dentro del testing tiene que ver con su eficiencia, ya sea medida en velocidad, capacidad de carga, rendimiento, resistencia a fallos de servicios externos y otras métricas.

Además de que haga aquello que queremos, también esperamos que el software lleve a cabo su tarea sin introducir errores, por lo que también hay un aspecto del testing que tiene como objetivo la localización y prevención de estos fallos.

Es decir, el testing cubre toda una serie de aspectos del proceso para asegurarnos de que estamos desarrollando el software correcto.

El software testing debería ir más allá de la detección de errores y problemas, ocupándose de asegurar que el producto de software alcanza los niveles de calidad deseados.

Reckless, Claire: So, What Is Software Testing?

A mano o a máquina

Verificar el funcionamiento de un software es tan sencillo como ejecutarlo, observar el resultado que produce y compararlo con el que esperábamos obtener.

Podemos hacerlo de forma manual o automatizarlo.

Testing manual

El testeo manual consiste simplemente en preparar una serie de casos para probar y ejecutar a mano los elementos necesarios.

Sus limitaciones deberían ser evidentes:

• Examinamos un número limitado de posibles casos, pero puede haber decenas de ellos.
• No tenemos ni idea de qué otros factores podrían estar influyendo en el resultado, ni podemos tenerlos realmente bajo control.
• No podemos garantizar que el mismo test, realizado por otra persona y en otras condiciones, vaya a dar el mismo resultado.

La primera objeción es la más fácil de resolver: es necesario definir una serie de condiciones de partida y casos posibles que probar. Por ejemplo, datos válidos y datos no válidos, datos que disparen ciertas condiciones, etc.

La segunda y tercera objeciones van bastante relacionadas: tenemos que asegurarnos de que las condiciones en las que se realizan los tests sean las mismas siempre y estén controladas. Por ejemplo, algo tan obvio como que las bases de datos tengan los mismos datos.

El testeo manual es lento y propenso a errores, y en muchas ocasiones es inviable en la práctica.

Testing automático

El testeo manual tiene muchas limitaciones:

• El proceso es lento, por lo que obtenemos el feedback tarde, lo que puede retrasar la salida a producción o la corrección de errores.
• Los tests pueden ser difíciles de replicar y obtener los mismos resultados, ya que depende de cosas como las condiciones de la prueba o incluso la persona que lo lleve a cabo.
• Se cubren pocos casos, con lo cual es fácil que queden multitud de errores y problemas que no se detectan hasta que es demasiado tarde.
• La granularidad de los tests es baja, ya que suelen hacerse las pruebas de la feature como un todo, con lo cual en caso de fallo aún queda un largo camino hasta encontrar la causa y corregirla.

La respuesta es automatizarlo.

Los tests automáticos son, esencialmente, programas que escribimos para probar el software. Las ventajas son muchas:

• Al estar escritos en un lenguaje de programación, los tests constituyen una descripción formal de las especificaciones del software.
• Los tests se ejecutan rápidamente, por lo que devuelven feedback muy pronto.
• Podemos realizar gran cantidad de tests y cubrir muchos más casos, añadiendo nuevos tests si descubrimos nuevas casuísticas o en caso de errores.
• Los podemos repetir cuantas veces necesitemos.
• Los tests automáticos son más fácilmente replicables e independientes de la persona que los realice.
• Es posible testear las aplicaciones en distintos niveles de abstracción, lo que permite tener mucha granularidad y precisión para detectar qué falla y dónde se produce el fallo.
• Finalmente, es posible automatizar el proceso de lanzamiento de los tests para, por ejemplo, ejecutarlos con regularidad o antes de desplegar una nueva versión del software, etc.

Khan, Abdullah: Manual Vs Automation Testing: The Pros and Cons

Qué sometemos a test

Una aplicación o producto de software puede observarse y, por tanto, testearse a distintos niveles.

• Globalmente, podemos testear puntos de entrada a la aplicación desde “el mundo exterior” y controlar su respuesta. A estos los llamamos tests end to end. También se suelen conocer como tests de aceptación, ya que representan las demandas de los interesados en el software.
• Igualmente, podemos testear módulos o subsistemas, para ver cómo funcionan sus componentes en interacción. Es lo que llamamos tests de integración.
• Finalmente, podemos testear de forma aislada las unidades componentes del software, como clases y funciones, lo que conocemos como tests unitarios.

Para hacernos una idea más clara, vamos a aplicar lo anterior a la fabricación de un producto físico como puede ser un coche:

• Los tests de aceptación consistirían en probar el coche terminado en un circuito con diversos tipos de condiciones, verificando no sólo que funciona, sino también si alcanza las prestaciones para las que ha sido diseñado.
• Los tests de integración serían aquellos que realizamos al montar las piezas que corresponden a cada subsistema, como podría ser todo el sistema de dirección, comprobando que el movimiento del volante se corresponde con el de las ruedas, etc. Para probarlo no sólo no hace falta montar el coche entero, sino que es preferible montar el sistema aislado del resto y probarlo.
• Los tests unitarios serían las pruebas que hacemos a cada pieza individual, de forma aislada, asegurándonos que tienen las características y prestaciones requeridas.

Cada nivel de tests tiene unas características y requisitos particulares y persigue unos objetivos distintos.

Los tests end-to-end o de aceptación, buscan probar que el sistema hace lo que se ha pedido y, como objetivo secundario, detectar errores generales. Para ejecutarlos requieren un entorno que sea equivalente al de producción. Este tipo de tests debería cubrir los diferentes casos de uso del sistema. Por su naturaleza son costosos de ejecutar.

Los tests de integración buscan probar que los elementos que forman un módulo interactúan de forma correcta, manteniéndolos aislados del resto del sistema. Si asumimos que los elementos individuales funcionan correctamente, estos tests nos ayudan a diagnosticar los problemas de comunicación entre ellos.

Finalmente, los tests unitarios prueban en aislamiento las unidades de software que, como hemos dicho, son clases y funciones. De este modo, es posible localizar con precisión problemas en su funcionamiento. Estos tests se ejecutan rápidamente, por lo que nos devuelven feedback muy pronto y tienen especial valor cuando estamos desarrollando.

Todos estos tipos de tests se agrupan, junto con otros, en los denominados tests funcionales, los cuales tratan sobre qué hace la aplicación.

Por otro lado, existen tests que nos dicen cómo desempeña la aplicación su tarea. Son los tests no funcionales, que miden cuestiones como el rendimiento, la tolerancia a fallos, la velocidad de respuesta y otras métricas.

Qué es hacer un test

Hacer un test, como hemos dicho, es comprobar si una pieza de software hace aquello que esperamos que haga. En ese sentido, podemos clasificar las piezas de software en dos tipos básicos:

• Queries: son piezas de software que devuelven una respuesta al ser ejecutadas. Por lo tanto, podemos tomar esa respuesta y compararla con la respuesta esperada.
• Commands: son piezas de software que provocan un cambio en el sistema. En consecuencia, para probar que se ha producido el cambio deseado debemos examinar aquella parte del sistema que debería haber cambiado.

Un test, en resumen, no es más que un programa que ejecuta una pieza de software y comprueba si su resultado, en el caso de las queries, o su efecto, en el caso de los commands, es el que se espera.

Normalmente escribimos los tests con ayuda de un framework o librería especializada, que nos aporta herramientas con las que gestionar y escribir más fácilmente nuestros tests, así como para ejecutarlos y obtener información útil de cada uno de ellos y del conjunto.

Estructura básica de un test

Ahora que tenemos clara la idea de que un test es un pequeño programa que ejecuta una unidad o componente de software para comprobar si su resultado es el que esperamos, vamos a analizar sus elementos.

La estructura de un test se puede representar de esta manera:

• Preparar unas ciertas condiciones
• Ejecutar la unidad de software bajo test
• Observar el resultado obtenido y compararlo con el esperado

Fundamentalmente, los tests tienen tres partes principales:

• Given o Arrange: La primera parte consiste en poner el sistema en un estado conocido, lo cual supone ajustar todas las variables que pueden afectar al test en un valor arbitrario determinado. En esta fase se disponen datos en una base de datos, se preparan los parámetros que se pasarán a la unidad probada, etc.
• When o Act: La segunda es la ejecución de la unidad de software y la obtención del resultado.
• Then o Assert: La tercera fase consiste en comparar el resultado obtenido con el resultado esperado. Normalmente esta operación se realiza con asserts o matchers, según el entorno de tests con el que trabajemos. Asserts y Matchers son utilidades de los frameworks de test que nos permiten verificar que el resultado obtenido coincide con el deseado.

Por otro lado, los tests deben estar aislados entre sí, de modo que unos no dependan o se vean afectados por el resultado de los otros.

Maksimovic, Zoran: The anatomy of a Unit Test

La elección de los casos para testear

¿Qué casos y cuántos casos deberíamos testear? Cuando vamos a realizar un test se nos plantea el problema de la elección de los casos que vamos a probar. En algunos problemas, los casos serán limitados y sería posible y rentable probarlos todos. En otros, tenemos que probar diversos parámetros que varían de manera independiente en proporción geométrica. En otros problemas, el rango de casos posible es infinito.

Entonces, ¿cómo seleccionar los casos y asegurarnos de que cubrimos todos los necesarios?

Para ello podemos usar diferentes técnicas, más allá de nuestra intuición basada en la experiencia o en las especificaciones del dominio. Estas técnicas se agrupan en dos familias principales:

• Tests de caja negra (black box): se basan en considerar la pieza de software que vamos a testear como una caja negra de la que desconocemos su funcionamiento. Sólo sabemos con qué datos podemos alimentarla y la respuesta que podemos obtener.
• Tests de caja blanca (white box): en este caso tenemos acceso al código y, por tanto, podemos basarnos en su flujo para decidir los casos de tests.

Tests de caja negra

Valores únicos

Si el número de casos es manejable podemos probar todos esos casos, más uno extra que represente los casos no válidos.

Supongamos un sistema de códigos de promoción que tiene los siguientes tres códigos. Queremos una función que devuelva el valor del código de promoción.

¿Qué valores debemos probar? Pues los tres valores válidos o posibles del código y un valor que no sea válido. Además, en este caso, podríamos probar que no haya valor.

Cuando el número de casos crece, podemos recurrir a diversas técnicas:

Equivalence Class Partitioning (Partición en clases de equivalencia)

Supongamos que tenemos una función que puede aceptar, potencialmente, infinitos valores. Por supuesto, es imposible probarlos todos.

Equivalence Class Partitioning es una estrategia de selección de casos que se basa en el hecho de que esos infinitos valores pueden agruparse según algún criterio. Todos los casos en un mismo grupo o clase son equivalentes entre sí a los efectos del test, de modo que nos basta escoger uno de cada clase para probar.

Algunos de estos criterios pueden venir definidos por las especificaciones o reglas de negocio. Veamos un ejemplo:

Supongamos una tienda online que haga descuentos en función de la cantidad de unidades adquirida. Para 10 ó más unidades, el descuento es del 10%; para 50 ó más unidades, el descuento es del 15%, y para 100 ó más unidades el descuento es del 20%.

Una función para calcular el descuento tendría que tomar valores de números de unidades y devolver un porcentaje. Esto se puede representar así gráficamente:

1 0    10                  50                      100
2 |----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
3   0 ][         10%       ][          15%         ][           20%   

En el gráfico se puede ver fácilmente que todos los valores que sean menores que 10 no tendrán descuento (0%), los valores desde 10 a 49 tendrán un descuento del 10%, los valores del 50 al 99, del 15% y los valores del 100 en adelante, del 20%. Nos basta escoger un valor cualquier de esos intervalos para hacer el test:

Boundary Value Analysis (Análisis de valor de límite)

Aunque la metodología anterior es perfectamente válida se nos plantea una duda: ¿cómo podemos tener la seguridad de que se devuelve el resultado correcto en los valores límite de los intervalos?

Usando Equivalence Class Partitioning seleccionamos un valor cualquiera dentro de cada intervalo. En Boundary Value Analysis vamos a escoger dos valores, correspondientes a los extremos de cada intervalo, excepto en los intervalos que no están limitados en uno de los lados:

Los dos valores escogidos para la prueba son válidos dentro de la definición de Equivalence Class Partitioning, con la particularidad de que al ser los extremos de los intervalos nos permiten chequear condiciones del tipo “igual o mayor”.

Decision table (tabla de decisión)

En las estrategias anteriores partíamos de la base de trabajar con un único parámetro. Cuando son varios parámetros los casos para probar se generan combinando los posibles valores de cada uno de ellos en una tabla de decisiones.

Imaginemos una tienda online de impresión de camisetas en la que el precio depende del modelo de camiseta (Masculino o Femenino), la talla (Pequeña, Mediana y Grande) y el tamaño de la ilustración (Pequeña o Grande). En ese caso, el número de posibles casos es 2 * 3 * 2 = 12, suponiendo que no habrá casos inválidos.

Esta casuística se representa en una tabla, más o menos como ésta:

Esta tabla nos permite generar todas las combinaciones de tal modo que cada columna representa un caso que deberíamos probar.

Tests de caja blanca

Basic path

Basic path es un tipo de diseño de tests que presupone el conocimiento del algoritmo que estamos testeando, de tal modo que diseñamos los casos de test en función de los caminos que sigue el flujo de ejecución del código. Por lo tanto, la cantidad de casos estará directamente relacionada con la complejidad ciclomática del mismo.

Por ejemplo, un código en el que no haya ninguna decisión, necesitaría un único caso de test. Si hay una decisión que crea dos caminos de ejecución, se necesitarán dos casos.

Normalmente, lo mejor es representar el diagrama de flujo del código para identificar fácilmente los diversos recorridos, identificando qué valores forzarán el paso por uno u otro.

Code coverage o Line Coverage

El índice de Code Coverage indica qué líneas de un código han sido ejecutadas o no por los tests. Normalmente se indica en porcentaje de líneas ejecutadas sobre líneas totales. Obviamente esta medida no nos dice nada acerca de la funcionalidad del código (si lo que hace es correcto o no) pero sí nos ayuda a detectar casos no testeados porque ciertas partes del código no se han llegado a ejecutar con las pruebas que tenemos.

Branch coverage

Aunque está estrechamente relacionado con el anterior, el branch coverage es un poco diferente. Su función es indicarnos si los posibles cursos de acción (o branches) de un código se han ejecutado.

Por ejemplo, una cláusula if…then que evalúa una condición tiene dos ramas, por tanto, ambas ramas deberían haberse ejecutado al menos una vez para asegurarnos de que han sido correctamente cubiertas. Si se evalúan dos condiciones, tendremos cuatro posibles combinaciones lógicas.

Frameworks para testing

Un framework para testing es un paquete de software que nos permite escribir tests de una manera sencilla, así como ejecutarlos y extraer información de interés.

Si no usamos un framework, podríamos escribir un test más o menos así, en pseudocódigo:

 1 function shouldCalculateFee()
 2 {
 3     // Given / Arrange 
 4     var consumption = 1000;
 5     var power = 1200;
 6     var optimalPower = 1150;
 7     
 8     // When / Act
 9     var fee = calculateFee(consumption, power, optimalPower);
10     
11     // Then / Assert
12     if (45 == fee) {
13         return 'ok'
14     } 
15     
16     throw Exception('CalculateFee failed')
17     
18 }

Usando un framework el test podría ser así:

 1 function shouldCalculateFee()
 2 {
 3     // Given / Arrange 
 4     var consumption = 1000;
 5     var power = 1200;
 6     var optimalPower = 1150;
 7     
 8     // When / Act
 9     $fee = calculateFee(consumption, power, optimalPower);
10     
11     // Then / Assert
12     assertEquals(45, fee);
13 }

Aunque el código es muy similar, usar un framework de test aporta varias ventajas:

• Ofrece un conjunto de aserciones que nos permiten verificar de forma expresiva diversos tipos de resultados de nuestras pruebas.
• Recopila información sobre la ejecución de los tests, mostrando estadísticas, tiempo de ejecución, etc.
• Facilita localizar los test que fallan.

Las aserciones (asserts o matchers) son funciones provistas por el framework de testing que encapsulan la comparación del resultado de la pieza de software probada con el criterio, junto con otras operaciones que permiten al sistema de testeo recopilar esa información. En último término una aserción no es otra cosa que una función que verifica que se cumple una condición. La variedad de aserciones nos permite que el código de nuestro tests sea más expresivo y conciso.

Existen varios tipos o familias de frameworks, según su orientación:

• xUnit: es el tipo más genérico. Los tests se estructura en TestCases y utiliza aserciones para verificar los resultados (JUnit, PHPUnit, etc).
• xSpec: los test de tipo Spec se usan en metodologías TDD o Behavior Driven Development y ponen el énfasis en la descripción del comportamiento esperado de las unidades bajo test (RSpec, phpspec, JSpec).
• xBehave: son frameworks para Behavior Driven Development, se orientan a la realización de tests de aceptación (JBehave, Cucumber, Behat).

Cuándo testear

Después de escribir el código

Testear después de desarrollar el código es una de las formas más habituales de trabajar, especialmente en la orientación que podríamos denominar de Quality Assurance (QA). La idea es probar que el código cumple las especificaciones y detectar posibles fallos o casos no cubiertos.

En resumen, consiste en escribir los tests una vez que hemos terminado de desarrollar el código de tal forma que podamos probar que cumple con las especificaciones y que no tiene fallos.

Esto presenta dos problemas principales:

El primero tiene que ver con la dificultad psicológica de poner a prueba nuestro código una vez lo consideramos terminado, ya que el test implica un trabajo extra que no siempre es fácil de realizar.

El segundo tiene que ver con la dificultad técnica de escribir buenos tests para un código que puede estar en un estado difícil de testear. Esto ocurre cuando en el desarrollo no se ha realizado una buena gestión de la dependencias y tenemos alto acoplamiento entre clases.

Antes de escribir el código

La idea de tener los tests antes que el código (test first development) es históricamente bastante antigua. Consiste en que los tests se escriben o definen antes de iniciar el desarrollo, de modo que su objetivo es conseguir que los tests se cumplan.

Why does Kent Beck refer to the “rediscovery” of test-driven development? What’s the history of test-driven development before Kent Beck’s rediscovery?

Obviamente al principio no se cumplirá ningún test puesto que no hay código que ejecutar. A la vez, esto es una guía que nos va indicando qué pasos debemos ir realizando.

Estrechamente ligada con esta idea está la metodología Test Driven Development (TDD). Las principales diferencias entre Test First Development y Test Driven Development son que, en TDD:

• Los tests se escriben uno a uno (no todos de una vez).
• Se escriben implementaciones lo más sencillas posible de código que consigan hacer pasar el test.
• Una vez que ha pasado el test, se revisa el código para eliminar duplicación y mejorar el diseño, asegurándonos de que el test se mantiene pasando.

tcagley: Test First and Test Driven Development: Is There a Difference?

Para describir un bug

Cuando detectamos un bug o un error en el código desplegado o en la fase de QA es buena idea escribir un test que, al fallar, ponga de manifiesto el problema observado.

A continuación, revisaremos el código para corregir el error y así hacer que el test que hemos escrito pase, manteniendo los otros tests pasando también. De este modo, nos aseguramos tanto de corregir el problema como de mantener el resto del sistema funcionando correctamente.

Para refactorizar un código

Cuando arrastramos deuda técnica, es decir código antiguo que es difícil de comprender y por tanto de mantener, es tentador tratar de reescribirlo para mejorar su inteligibilidad. Para esos casos es útil introducir los llamados tests de caracterización.

Se trata de tests que creamos a partir del funcionamiento actual de la pieza de software que estamos estudiando. Usando su resultado actual como criterio de comparación del test. La idea es no alterar ese resultado con los cambios que hagamos en el código.

Testing en contexto

Taxonomía de tests

Los tests de software se pueden agrupar en dos grandes categorías globales:

• Tests funcionales
• Tests no funcionales

Tests funcionales

Los tests funcionales se refieren a los tests que prueban que el software hace aquello para lo que ha sido diseñado. Esto es, por ejemplo, una aplicación para gestionar la venta de productos de segunda mano permite a sus usuarios comprar y vender artículos de segunda mano y todo lo que eso conlleva, como dar de alta productos con sus precios, descripciones y fotos, contactar con vendedores y compradores, gestionar pagos, etc.

Esto se puede probar a varios niveles, a saber:

• Tests unitarios: probando las unidades básicas en que está organizado el software funcionando de manera aislada.
• Tests de integración: probando conjuntos de unidades básicas que están relacionadas entre sí, para comprobar que sus relaciones funcionan correctamente.
• Tests de aceptación: probando los puntos de entrada y salida del software para comprobar que su comportamiento es el definido por los stakeholders (quienes están interesados en su uso)

Estos tres niveles componen la llamada “pirámide de tests” que comentaremos posteriormente.

Además de los anteriores, entre los tests funcionales también consideramos:

• Tests de regresión: son tests que pueden detectar las consecuencias de los cambios que hayamos podido realizar en el software que nos llevan a un comportamiento no deseado. Se puede decir que todos los tipos de tests son tests de regresión en tanto que una vez que hayan pasado correctamente fallarán si se realizan cambios en el software que alteren el comportamiento esperado.
• Tests de caracterización: son tests que se escriben cuando el software no tiene otros tests y normalmente se crean ejecutando el software bajo unas condiciones determinadas y observando el resultado que arroja. Ese test se utiliza como red de seguridad para realizar cambios y también mejores tests.

Test Driven Development puede practicarse también en los tres niveles. La idea es que se definen primero los tests y se escribe el código para que los tests pasen. Una vez que esto se logra, tras eliminar posibles redundancias, los tests escritos se convierten automáticamente en tests de regresión.

Tests no funcionales

Los tests no funcionales se refieren a cómo trabaja el software. Al margen de que aporte una funcionalidad, es necesario que el software ofrezca una fiabilidad, capacidad de respuesta, etc, algo que es transversal a todo tipo de aplicaciones y que se puede medir de diversas maneras. Estos tests prueban cosas como, entre otras:

• Velocidad: Nos dice si el software devuelve resultados en el tiempo deseado.
• Carga: Nos dice si puede soportar un volumen de trabajo determinado, lo cual puede tener diversas medidas: conexiones simultáneas, volumen de datos que puede procesar de una sola vez, etc.
• Recuperación: Nos dice si un sistema es capaz de recuperarse correctamente en caso de fallo.
• Tolerancia a fallos: Nos dice si el sistema reacciona correctamente si se producen fallos en otros sistemas de los que depende.

En algunos casos, los tests de aceptación nos pueden ayudar a controlar a grosso modo algunos aspectos que corresponden a tests no funcionales. Por ejemplo, cómo reacciona nuestro sistema si no puede acceder a información de otros sistemas.

Los tests no funcionales buscan controlar que el sistema se comporta dentro de ciertos parámetros y que reacciona correctamente a ciertas contingencias que se encuentran fuera de su alcance.

Esencialmente los tests no funcionales siguen el mismo esquema que los tests funcionales:

• Se define un escenario o estado inicial del sistema (Given).
• Se ejecuta una acción sobre el sistema (When).
• Se observa la respuesta del sistema para ver si coincide con la esperada (Then).

Por ejemplo, podríamos decidir que una página web debe esta lista en menos de un segundo con una velocidad de red determinada para que un usuario pueda interactuar con él (o bien un tabla de velocidades de red típicas y tiempos de respuesta). Por tanto:

• Ponemos el sistema en un estado conocido asumiendo ciertas condiciones.
• Medimos el tiempo que tarda en estar listo para aceptar una entrada.
• Comprobamos si ese tiempo es menor que el deseado.

La pirámide de tests funcionales

La pirámide de tests funcionales es un heurístico para decidir la cantidad de tests de cada nivel que realizamos.

La idea es algo más o menos así:

• Test unitarios: están en la base de la pirámide y deberíamos tener muchos
• Test de integración: están en la parte media de la pirámide y deberíamos tener menos
• Test de aceptación: están en lo alto de la pirámide y deberían ser pocos

O dicho de otra forma:

Dada una feature de nuestro software tendríamos:

• Unos pocos tests de aceptación que cubran los escenarios definidos por los stakeholders.
• Un número mayor de tests de integración que aseguren que los componentes del sistema funcionan correctamente en interacción y que saben reaccionar a los fallos de los demás.
• Un gran número de tests unitarios que nos aseguren que las unidades de software hacen lo que se espera de ellas y son capaces de manejar las distintas condiciones de entrada, así como reaccionar correctamente en caso de entradas no válidas.

Pero, ¿por qué?

Muchos tests unitarios

Los tests unitarios, al centrarse en una sola unidad de software en aislamiento, deberían ser:

• Fáciles de escribir: una unidad de software debería tener que manejar relativamente pocas casuísticas y reaccionar ante problemas de una forma sencilla, normalmente lanzando excepciones.
• Rápidos: en caso de haber dependencias estas estarían dobladas por objetos más sencillos y menos costosos, permitiendo que la ejecución de los tests sea muy rápida.
• Replicables: podemos repetir los tests cuantas veces sea necesario, obteniendo los mismos resultados si el comportamiento de la unidad de software no ha sido alterado.

Estas condiciones nos permiten hacer cosas como:

• Ejecutar los tests cada vez que hagamos un cambio en el software, lo que nos proporciona feedback inmediato en caso de cualquier alteración del comportamiento.
• Puesto que los tests prueban una unidad concreta de software en un escenario específico, si fallan obtenemos un diagnóstico inmediato del problema y dónde se ha producido.

Por estas razones, lo lógico es tener muchos tests unitarios que puedan ejecutarse rápidamente muchas veces al día: cuando realizamos un cambio, en el momento de enviar commits, en el momento de desplegar, etc.

¿Más es mejor? Como en tantos aspectos de la vida, más no es necesariamente mejor, pero nos interesa que entre todos los tests de una unidad de software se cubran todas las casuísticas relevantes, de modo que cuando uno de ellos falla podamos saber qué cambio concreto hemos realizado que ha provocado el problema.

En los tests unitarios, los comportamientos de otras unidades de software que pudiesen intervenir se simulan mediante test doubles, los cuales se limitan a devolver respuestas prefijadas de modo que el output de la unidad de software sólo pueda ser atribuido a su propio comportamiento, manteniendo controlado el de los colaboradores.

Un número medio de tests de integración

Los tests de integración ejercitan varias unidades de software que están interrelacionadas para un proceso dado, pero de forma aislada al resto de la aplicación.

En este caso no se simula ningún comportamiento puesto que nuestro objetivo es ver si las unidades de software interactúan de la forma prevista. Es posible que sí tengamos que simular el comportamiento de sistemas externos al nuestro (por ejemplo, una API que nos proporciona ciertos datos, etc.). Obviamente utilizamos datos específicamente creados para la situación de test.

La casuística aumenta en proporción geométrica al número de unidades implicadas pues es el producto del número de casos que tiene que manejar cada unidad.

El problema es que además de aumentar el número de casos, los tests de integración son más lentos que los unitarios, por lo que debemos tomar un enfoque diferente.

El test de integración no tiene que verificar que cada una de las unidades realiza bien su trabajo, eso es algo que ya habrá probado nuestro test unitario, sino que probará el comportamiento del sistema de unidades, particularmente los casos en que alguna de las unidades falla por un motivo u otro, para asegurarnos de que las demás reaccionan de una forma manejable.

Un número pequeño de tests de aceptación

Los tests de aceptación prueban el sistema desde el punto de visto de sus usuarios o stakeholders, por tanto, ejercitan todos los componentes del sistema implicados en una acción concreta. En los tests de aceptación no se simulan comportamientos de nuestro sistema, aunque es posible que tengamos que simular otras sistemas externos o condiciones de ejecución.

Nuestras pruebas de aceptación se ejecutan en un entorno específico de tests que sería idéntico al de producción.

Por lo general, en los tests de aceptación nos interesa probar ciertos escenarios que son significativos para los stakeholders. Por ejemplo:

• Un usuario que quiere contratar un servicio y aporta los datos necesarios debe recibir una confirmación de que ha contratado el servicio.
• Un usuario que quiere contratar un servicio y no aporta los datos necesarios (o son incorrectos) debe recibir una información de qué datos debería corregir y que no se ha contratado el servicio.
• Un usuario que quiere contratar un servicio debe recibir una información adecuada en caso de que haya algún fallo del sistema que impida completar el proceso.

Muchos tests de aceptación pueden realizarse con este simple modelo:

• Input correcto del usuario + sistema correcto -> output correcto del sistema
• Input incorrecto del usuario + sistema correcto -> output informativo del sistema
• Input correcto del usuario + sistema incorrecto -> output informativo del sistema

Obviamente muchos procesos tienen una diversidad de escenarios para considerar que aumentan el número de tests necesarios. Sin embargo, su número será menor que el de todas las combinaciones de casos de los tests unitarios que ejercitan las unidades de software implicadas.

Los tests de aceptación se pueden escribir con lenguaje Gherkin, que es una forma estructurada de definir features mediante escenarios usando lenguaje natural. De este modo, los stakeholders o los product owners pueden contribuir a definirlos conjuntamente con los desarrolladores. Posteriormente se traducen a un lenguaje de programación usando herramientas como Cucumber o Behat.

Utilidad de la pirámide de tests

La primera utilidad de la pirámide de tests es ayudarnos a definir cuántos tests necesitamos en cada uno de los niveles. De todos modos es sólo un heurístico ya que la proporción entre los tres niveles también es significativa y no es fácil definir una correcta.

La pirámide de tests nos proporciona tres niveles de resolución a la hora de analizar el comportamiento de nuestra aplicación.

• El nivel de aceptación nos permite observar los procesos de la aplicación como una unidad.
• El nivel de integración nos permite observar los procesos en los sub-sistemas que están implicados y los fallos en estos tests nos indican, sobre todo, fallos de comunicación entre unidades.
• El nivel unitario nos permite observar las unidades de software y los fallos en este nivel nos permiten diagnosticar nuestros algoritmos.

Idealmente, con una buena proporción de tests nos encontraríamos que un test que no pasa en el nivel de aceptación se reflejaría en tests que no pasan en alguno de los otros niveles:

• Si fallan tests en el nivel de integración (pero no en unitarios) nos estaría indicando que algunas unidades de software no se comunican bien entre sí, por ejemplo, porque una está entregando datos en formatos inadecuados.
• Si fallan tests en el nivel unitario (seguramente también estará fallando el nivel de integración) indica que alguna unidad de software está funcionando mal.

A veces es más informativa la ausencia de fallos:

• Los fallos en los tests de aceptación que no tienen reflejo en fallos en los tests de integración o unitarios nos dicen que nos hemos dejado casos de test en el tintero. Los tests de aceptación que fallen deberían llevarnos a crear nuevos tests en los demás niveles.
• Si los tests unitarios fallan y no fallan los tests de nivel superior, nos está diciendo que nos faltan tests en esos niveles. Un test unitario que falla debería reflejarse en un test de integración y un test de aceptación fallando igualmente.

La pirámide, por otra parte, nos ayuda a controlar que la ejecución de los tests se mantenga en un nivel que la haga práctico:

• Los tests de aceptación son muy lentos. Si tenemos relativamente pocos (siempre que sean suficientes, claro) lograremos que se ejecuten en el menor tiempo posible y podríamos lanzarlos automáticamente antes de cada deploy.
• Los tests de integración son medianamente rápidos, si los mantenemos en un nivel adecuado podríamos ejecutarlos automáticamente en cada pull request.
• Los tests unitarios son muy rápidos, por lo que podríamos ejecutarlos en cada commit.

Para que esta estructura sea realmente eficaz, tendríamos que asegurarnos de que un fallo en un nivel se refleja en los otros dos.

Obviamente podemos optimizar la ejecución de tests mediante herramientas que nos ayuden a ejecutar sólo aquellos afectados por los últimos cambios.

Smells en la pirámide de los tests funcionales

Observando la proporción entre los tests en los tres niveles podemos diagnosticar si nuestra batería de tests está bien proporcionada. En caso de que no sea así, el objetivo debería ser incrementar la cantidad de tests en los niveles que lo necesitan así como revisar aquellos niveles que podrían tener tests redundantes.

En general, un excesivo número de tests del nivel de aceptación con respecto al unitario nos permite detectar fallos, pero no diagnosticarlos con precisión.

Por otra parte, demasiados tests unitarios con pocos tests de aceptación probablemente pase por alto muchos errores que se revelarán en producción.

Pirámide invertida

La pirámide invertida indica que hay pocos tests unitarios y muchos tests de aceptación.

Muchos tests de aceptación podrían indicar que se prueban escenarios innecesarios o que se intenta comprobar el funcionamiento de unidades concretas del sistema desde fuera intentando suplir con tests de aceptación la necesidad de tests unitarios.

Pocos tests unitarios hacen difícil o imposible determinar con facilidad dónde están los problemas cuando los tests de nivel superior fallan.

Pirámide aplastada

La pirámide aplastada indicaría que hay demasiados pocos tests de aceptación respecto a los tests unitarios. Si suponemos una situación en que la cobertura de tests unitarios es adecuada, lo que nos está diciendo este smell es que tenemos que realizar más pruebas de integración y de aceptación.

En esta situación los tests no nos dicen mucho acerca de cómo se comporta la aplicación como un todo y probablemente estamos confiando demasiado en tests manuales. En consecuencia no podremos identificar casos problemáticos que estarán relacionados con mala comunicación entre las diversas unidades de software.

Forma de diábolo

Nos indicaría que tenemos pocos tests de integración y que son los tests de aceptación los que están haciendo su trabajo. Tendríamos que analizar los tests de aceptación y mover pruebas al nivel de integración.

En caso de fallo en el nivel de aceptación nos encontraríamos que si los tests unitarios no fallan no podemos saber qué interacción de nuestras unidades está funcionando mal.

Forma de rombo

La forma de rombo nos indica que los tests de integración están haciendo el trabajo de los tests unitarios. Un fallo en este nivel no nos aclara si es debido a un problema de integración o a un problema en una unidad concreta de software.

La solución es crear más tests unitarios que nos ayuden a discriminar mejor.

Forma de cuadrado

Si en lugar de una pirámide tenemos una forma parecida a un cuadrado es que tenemos un número similar de tests en cada nivel. Esto indica que o bien tenemos pocos tests unitarios o bien tenemos demasiados tests de integración y aceptación que, probablemente, estén haciendo el trabajo de niveles inferiores.

Psicología del testing

Mi primer contacto con los tests, con el propio concepto de test para ser precisos, fue de todo menos una epifanía.

Al principio conseguí desarrollar una noción bastante vaga de la idea y necesidad de testear software, la cual, afortunadamente, fui elaborando y perfeccionando con el tiempo. Aún hoy sigo trabajando en refinarla.

Asimismo me costó entrar en la técnica del testing. En aquel momento había pocas referencias en el mundo PHP y tampoco es que hubiese mucho interés en hacer pedagogía sobre cómo escribir tests, no digamos ya buenos tests. Toda mi documentación era la que proveía SimpleTest, un framework de la familia JUnit del que no sé si se acordará alguien todavía.

Ni te cuento el shock mental que supuso encontrarme con las metodologías test-first y test driven development. Por entonces, no me cabía en la cabeza la idea de no tener que preparar un montón de cosas antes de plantearme siquiera poder empezar a escribir el test más simple. En aquella época, un ‘Class Not Found’ era un error, no una indicación de mi siguiente tarea.

Hoy por hoy, después de varios años, ha llegado un punto en el que me cuesta escribir software sin empezar por los tests. Con ellos defino mis objetivos al escribir código o tiendo redes de seguridad para realizar modificaciones y rediseños. Como programador, mi vida es ciertamente mejor con tests.

¿Por qué nos cuesta el testing?

Técnicamente hablando, hacer tests es algo bastante simple. Un test no es otra cosa que un pequeño programa que ejecuta una unidad de software y nos dice si el valor devuelto coincide o no con uno predeterminado, o bien, si produce un efecto que esperamos.

En último término, un test es esto:

1 $result = // exec some software unit
2 
3 if ($expected === $result) {
4 	echo 'OK: the software unit works as expected';
5 } else {
6 	echo 'Something is wrong!'
7 }

Claro que para trabajar profesionalmente necesitamos herramientas y frameworks algo más potentes, y tenemos el problema de definir qué es una unidad de software, así como delimitar lo que entendemos como resultado esperado.

Pero no vamos a tratar aquí de esas cuestiones.

Nuestro objetivo es llamar la atención sobre una serie de aspectos que podríamos definir como psicológicos y que contribuyen a explicar por qué la práctica del testing no está tan extendida como cabría esperar.

El concepto de test y la necesidad de testear

¿Cómo sabemos que un software funciona? Pues sencillamente viéndolo funcionar. Un primer problema en el acercamiento al testing es que vemos que el software que acabamos de escribir funciona. De hecho, hablamos muchas veces de testeo manual en se mismo sentido: observamos si el código que hemos escrito se comporta como deseábamos y, si es así, lo consideramos terminado. En caso contrario, intentamos comprender por qué ha fallado y procuramos corregirlo, comenzando el ciclo de nuevo.

Esta es una de las primeras barreras: si vemos que el código funciona: ¿por qué debería dedicar tiempo y esfuerzo a crear un test para decir lo mismo?

He aquí algunas razones:

1. Un test es una definición formal de lo que entendemos por funcionamiento correcto del software en la que las distintas personas interesadas podremos estar de acuerdo.
2. Es replicable: el test dará el mismo resultado ejecutado en diversos entornos, no depende de si estamos prestando atención o si recordamos cuál era el resultado que tenía que dar.
3. Es repetible: podemos repetir el test cuantas veces queramos, de modo que podemos hacer cambios en el código y asegurarnos de que sigue dando el mismo resultado.
4. Es automatizable: podemos programar la ejecución del test en cualquier momento que necesitemos, junto con todos los demás test que tengamos.

Es decir, la afirmación que yo pueda hacer sobre el funcionamiento de mi código no tiene el mismo peso cuando no está corroborada por tests que cuando sí lo está. El test es una medida del funcionamiento adecuado del software.

Otra cuestión sería la discusión de si estamos midiendo de la forma correcta con un test dado. Pero precisamente, el hecho de que exista un test nos permite evaluar si ese test mide lo que queremos que mida.

Sentimos apego por nuestro código

Tendemos a sentir apego por nuestro código. Puede ser feo, pero es el nuestro. En realidad nunca lo vemos feo, nos parece un unicornio blanco y hermoso.

Para decirlo de forma más técnica y menos dramática: todos tenemos un cierto prejuicio a favor de nuestro propio código, así que puede costarnos esfuerzo ponerlo a prueba. No por las dificultades técnicas que supone, de lo que trataremos más adelante, sino por la disonancia que nos genera ser críticos con nuestra propia obra.

En particular, señalaría estos factores que influyen en la dificultad psicológica de poner a prueba el código creado por nosotros:

1. Tarea terminada: cuando conseguimos que un código funcione tenemos la sensación de haber cumplido con la tarea, por lo que la fase de testing se convierte en un extra difícil de asumir. Nuestra mente se ha puesto en modo de “buscar la siguiente tarea”.
2. La solución única: la mayoría de nosotros hemos pasado por un sistema educativo que ha inculcado en nuestros cerebros la idea de que sólo hay una solución correcta para los problemas. Una cultura maniquea, en la que las cosas o están bien o están mal y en la que la evaluación se percibe como un peligro más que como una forma de diagnostico (a ver si va a fallar el test en algún caso raro).

Pero, ¿cómo librarse de esta visión subjetiva del propio código? Probablemente la mejor forma sea utilizando un enfoque test first, como TDD y BDD.

Al tener los tests antes que el código conseguimos:

• Que sean los tests los que nos digan cuál es nuestro siguiente paso: la tarea no termina hasta que no pasan todos los tests.
• Al no tener código previo no tenemos un prejuicio hacia un diseño u otro, sino que lo vamos definiendo en consonancia con lo que los tests nos piden.
• En todo momento podemos decir cuál es el estado del código, pues hemos formulado las especificaciones como tests y sabemos cuales se cumplen y cuales todavía no.

La dificultad técnica del testing

Como ya sabemos hay muchos diseños que hacen especialmente difícil testear un código. En particular, cuando se tiene un alto acoplamiento o dependencias globales.

Esta dificultad puede llevarnos a evitar la etapa de testeo o reducirla solo a la comprobación del happy path.

Aunque hay técnicas específicas para lidiar con estas situaciones, lo ideal es el enfoque test first. Para poder cumplir con los tests, nuestro diseño lo tiene en cuenta desde el inicio y las situaciones problemáticas (acoplamiento, dependencias de estado global, etc) se manifiestan de manera inmediata, obligándonos a adoptar soluciones que reducen o evitan esos problemas.

La presión para no testear

La necesidad o la prisa de sacar productos o features al mercado puede generar una presión de la organización para entregar cuanto antes. En consecuencia, todo lo que no contribuye a ese objetivo tiende a dejarse de lado, y el testeo suele ser una de las primeras cosas que se abandona cuando se pretende ir ligero.

Volviendo al punto anterior, la sensación de tarea terminada es determinante aquí: “si el producto funciona, ¿para qué debería testearlo?”

La respuesta es otra pregunta: ¿cómo puedes decir que el producto funciona si no lo has testeado?

Es habitual tener la siguiente experiencia: dedicar un tiempo a desarrollar un código, entregarlo y tener que emplear el mismo tiempo o más para corregir detectar y corregir errores que se han manifestado tras entregar el producto. De tal modo que la definición de producto terminado queda completamente cuestionada: ¿podemos decir que un producto está terminado si tenemos que corregir errores que impiden su funcionamiento en muchos de los casos de uso habituales?

Ese tiempo que hemos tenido que dedicar a corregir errores hubiera podido dedicarse a prevenirlos mediante un testeo adecuado que guiase el desarrollo. No sólo eso, los errores pueden tener consecuencias en forma de pérdida de ingresos, publicidad negativa, etc, que son medibles y, muy probablemente, supongan un mayor coste que haber tratado de garantizar una buena cobertura de tests.

Testear no es igual a confirmar que funciona

En la visión popular de la ciencia es habitual pensar que un experimento exitoso demuestra el acierto de una teoría. Pero esto no es así, el objetivo de los experimentos es justamente lo contrario. Es lo que se denomina falsabilidad.

Siguiendo la idea de la falsabilidad, un experimento exitoso no demuestra que la teoría en la que se basa es verdadera, sino que no es falsa hasta donde ha sido probada. Y ese cambio de visión es fundamental: el experimento se diseña con la idea de refutar la teoría, de modo que si no funciona nos aporte información, señalando cuáles son sus límites, y podamos aceptarla o rechazarla provisionalmente.

Con los tests de software pasa algo parecido. Un test determinado puede pasar, pero eso no garantiza que el software funcione bien, ya que puede haber casos en los que no. Los test deberían buscar el fallo del software, es decir, probar aquellos casos que pondrían en cuestión su funcionamiento. Cuantos más de estos casos podamos expresar en forma de test, con más solidez podremos afirmar que el software funciona.

Un test de happy path, es decir, un test que sólo ejercita el flujo perfecto de nuestro código no nos garantiza el funcionamiento del mismo, aunque ciertamente nos ayuda proporcionando una representación formal de cuál debería ser su comportamiento.

Responsabilidad ética y testeo

Nuestro mundo está cada vez más basado en el software. ¿Te has parado a pensar alguna vez en las consecuencias de que tu código funcione como se espera o no?

Si una arquitecta o un ingeniero diseñan una estructura que resulta estar mal calculada y se derrumba tienen una responsabilidad civil. Piensa en el perjuicio económico que ello causaría. Pero, ¿y si ese derrumbe provoca lesiones o muertes?

¿En qué producto de software estás trabajando? Hoy en día, el software controla todo tipo de dispositivos y todo tipo de servicios. Por poner unos pocos ejemplos:

• Un error podría provocar que un usuario pierda una cantidad de dinero, al pagar por un servicio que nunca recibirá: ¿cómo de grande es la pérdida para esa persona?.
• Otro error podría dar lugar a un diagnóstico erróneo de un paciente en un hospital y, en consecuencia, un tratamiento inapropiado.
• Otro error podría impedir a una persona viajar para presentarse a una entrevista de trabajo y perder una oportunidad de empleo que tal vez no vuelva a darse.

Las consecuencias del mal funcionamiento del software van más allá de una molestia o de un perjuicio económico para una persona o empresa y son imposibles de predecir para nosotros.

El contexto es fundamental y es cierto que no es lo mismo escribir software para un supermercado online, que hacerlo para un sistema de navegación aeronáutica o un software de ayuda al diagnóstico médico. En base a ese contexto podemos prever una serie de posibles consecuencias y tomar medidas adecuadas. Cada uno de estos contextos tiene distintas exigencias en cuanto a la fiabilidad y exactitud del funcionamiento de nuestro código. Pero ello no nos libera de la responsabilidad de hacerlo lo mejor posible y el testing es un medio para lograrlo.

El testing no es garantía de un software sin defectos, es cierto, pero es la demostración de que estamos tomando medidas para crearlo de la mejor manera posible.

Primer test

Un test no es más que una pieza de código que comprueba el resultado generado por otra pieza de código, comparándola con un criterio:

 1 function triple(float $number)
 2 {
 3     return $number * 3;
 4 }
 5 
 6 function test()
 7 {
 8     $result = triple(5);
 9     
10     if (15 === $result) {
11         echo 'Pass';
12     } else {
13         echo 'Fail';
14     }
15 }
16 
17 test();
18 
19 >>> Pass

En este ejemplo, la función test llama a la función triple con un valor y compara el resultado, convenientemente guardado en $result, con un valor esperado. En caso de que coincida imprime ‘Pass’ y, en caso de que no, imprime ‘Fail’.

Este sistema funciona para un sólo test, pero es poco eficaz cuando queremos hacer más de uno. No digamos los cientos o miles que debería tener una aplicación mediana.

Veamos sus limitaciones más importantes:

• Tener que definir la estructura condicional, que es el meollo del test, para cada test que creamos.
• Tener que montar algún tipo de runner para ejecutar todos los tests de una aplicación de una sola vez, o tener que ejecutarlos uno por uno.
• No recoger información sobre la ejecución de los tests: los que han pasado, o los que han fallado.
• No recoger información acerca de cuáles son las diferencias encontradas entre el resultado obtenido y el esperado.

Frameworks al rescate

Para superar estas limitaciones, se han creado frameworks de testing que nos aportan:

Aserciones o matchers que encapsulan la comparación del resultado esperado y el obtenido, aportándoles significado. Por ejemplo: assertEquals comprueba que sean iguales, assertGreaterThan verifica que el resultado obtenido sea mayor que un criterio dado, assertTrue verifica que una condición se cumple, y así muchas más.

Runner: los frameworks de tests utilizan un runner que recopila todos nuestros tests, o el subconjunto que indiquemos mediante algún tipo de criterio, y los ejecuta con una sola orden, optimizando el tiempo.

Estadísticas: los runners recogen estadísticas acerca de la ejecución de los tests. Pueden seguir corriendo, o no, cuando alguno de los tests falla y nos muestran información de qué tests se han ejecutado, cuáles han pasado, cuáles han fallado, o pueden analizar la cantidad de código cubierto por los mismos.

Análisis de diferencias: las aserciones que no se cumplen nos muestran comparaciones de los valores esperados con los obtenidos, lo que nos puede ayudar a analizar qué errores podemos haber cometido o dónde debemos intervenir para corregir el código.

Por tanto, la mejor manera de escribir tests es utilizar un framework que nos proporcionará todas las herramientas que podamos necesitar.

En los ejemplos de este libro utilizamos phpunit que es prácticamente el estándar, aunque ciertamente hay otros frameworks. Algunos de ellos parten de ciertos planteamientos metodológicos, como puede ser el Behavior Driven Development, una variante de TDD. Otros se especializan en tipos de tests específicos o complementan de algún modo el trabajo que podemos hacer con phpunit, o incluso se basan en él.

Sobre la instalación y puesta en marcha de phpunit, además de la documentación propia del framework, puedes recurrir a los apéndices del libro, donde lo explicamos.

El primer test

Vamos a suponer el siguiente código en el que se modela un carro de la compra para una tienda online.

La implementación es bastante mala y esto es a propósito, así que no te fijes mucho en ella. En este capítulo no vamos a discutir los detalles de su desarrollo, sino que vamos a ver cómo podríamos poner bajo test un código ya escrito y cómo eso nos puede servir para detectar problemas en un código ya existente.

Aquí tienes: src/Shop/Cart.php

  1 <?php
  2 declare(strict_types=1);
  3 
  4 namespace Dojo\Shop;
  5 
  6 use ArrayIterator;
  7 use Countable;
  8 use DomainException;
  9 use Iterator;
 10 use IteratorAggregate;
 11 use UnderflowException;
 12 
 13 class Cart implements IteratorAggregate, Countable
 14 {
 15     /** @var string */
 16     private $id;
 17     /** @var array */
 18     private $lines;
 19 
 20     public function __construct(string $id)
 21     {
 22         $this->id = $id;
 23         $this->lines = [];
 24     }
 25 
 26     public static function pickUp(): Cart
 27     {
 28         $id = md5(uniqid('cart.', true));
 29 
 30         return new static($id);
 31     }
 32 
 33     public static function pickUpWithProduct(
 34         ProductInterface $product,
 35         int $quantity
 36     ): Cart {
 37         $cart = static::pickUp();
 38 
 39         $cart->addCartLine(new CartLine($product, $quantity));
 40 
 41         return $cart;
 42     }
 43     
 44     public function drop()
 45     {
 46         $this->lines = [];
 47     }
 48 
 49     public function id(): string
 50     {
 51         return $this->id;
 52     }
 53 
 54     public function addProductInQuantity(
 55         ProductInterface $product,
 56         int $quantity
 57     ): void {
 58         $this->addCartLine(new CartLine($product, $quantity));
 59     }
 60 
 61     public function removeProduct(ProductInterface $product): void
 62     {
 63         if (!isset($this->lines[$product->id()])) {
 64             throw new UnderflowException(
 65                 sprintf('Product %s not in this cart', $product->id())
 66             );
 67         }
 68 
 69         unset($this->lines[$product->id()]);
 70     }
 71     
 72     public function amount(): float
 73     {
 74         return array_reduce(
 75             $this->lines,
 76             function (
 77                 float $accumulated,
 78                 CartLine $line
 79             ) {
 80                 $product = $line->product();
 81                 $accumulated += $product->price() * $line->quantity();
 82                 return $accumulated;
 83             },
 84             0
 85         );
 86     }
 87 
 88     public function totalProducts(): int
 89     {
 90         return array_reduce(
 91             $this->lines,
 92             function (
 93                 int $accumulated,
 94                 CartLine $line
 95             ) {
 96                 $accumulated += $line->quantity();
 97 
 98                 return $accumulated;
 99             },
100             0
101         );
102     }
103 
104     public function isEmpty()
105     {
106         return 0 === $this->count();
107     }
108 
109     public function count(): int
110     {
111         return \count($this->lines);
112     }
113 
114     public function getIterator(): Iterator
115     {
116         return new ArrayIterator($this->lines);
117     }
118 
119     private function addCartLine(Cartline $cartLine): void
120     {
121         $product = $cartLine->product();
122         $this->lines[$product->id()] = $cartLine;
123     }
124 }

¿Qué es lo que podríamos testear primero? Lo mejor es empezar un poco antes, tratando de tener claro cuál es el comportamiento que esperamos de nuestro carro. Podemos escribir una lista de especificaciones que sería más o menos como esta:

• Un carro nuevo se instancia autoasignándose un id y no contiene productos.
• Un carro nuevo puede instanciarse cuando un usuario selecciona un producto y lo añade a un carrito que todavía no existe.
• Podemos añadir productos al carro, indicando cuántos se añaden.
• Si se añade un producto que ya existe, se incrementa su cantidad.
• Se pueden quitar productos del carro, decrementando su cantidad.
• El carro nos puede decir si tiene productos o está vacío.
• Podemos obtener un recuento del total de productos que contiene.
• Podemos obtener un recuento del total de productos diferentes que contiene.
• Podemos obtener el importe total de los productos que contiene.
• Podemos vaciar por completo el carro.

Testeando la instanciación

Tiene bastante sentido comenzar testeando que el carrito se instancia correctamente tal y cómo esperamos. Para plantear el test debemos pensar en tres cosas:

• En qué escenario o precondiciones se va a ejecutar el test.
• De qué modo tenemos que accionar el objeto bajo test.
• Cómo vamos a obtener el resultado o consecuencias observables de esa acción.

En nuestro ejemplo, tenemos dos escenarios posibles para la instanciación. En uno de ellos el carrito se crea vacío, mientras que en el otro, se crea añadiendo un producto.

Observando el código, podemos ver que un carro nuevo se obtiene mediante un named constructor:

1 $cart = Cart::pickUp();

Y lo que queremos comprobar es que se le ha asignado un identificador y que no contiene ningún producto.

1 $id = $cart->id();
2 $numberOfProducts = $cart->count();

Con estas piezas podemos montar nuestro primer test.

En phpunit solemos agrupar los tests relativos a una misma clase en un Test Case. Un Test Case extiende de TestCase, una clase básica para test que te proporciona todas las herramientas que necesitas para trabajar.

La convención dice que el nombre del Test Case es el mismo que el de la clase con el sufijo Test. Este sufijo es necesario para que la configuración por defecto de phpunit pueda encontrar los tests que debe ejecutar. Puedes definir otro sufijo si lo deseas, pero no vamos a entrar en eso ahora.

Ahora bien, esto es una convención. No implica ningún tipo de obligación o requisito técnico. Puede que te interese tener varios Test Case para probar la misma clase, pero agrupando casos por diferentes criterios que a ti o a tu equipo le resulten significativos.

Aquí está tests/Dojo/Shop/CartTest.php

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo\Shop;
 5 
 6 use Phpunit\Framework\TestCase;
 7 
 8 class CartTest extends TestCase
 9 {
10 }

Ahora vamos a escribir un test que pruebe lo que hemos dicho sobre la instanciación de un carrito de la compra nuevo. Lo primero es escribir un método, que contiene el código del test:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo\Shop;
 5 
 6 use Phpunit\Framework\TestCase;
 7 
 8 class CartTest extends TestCase
 9 {
10     public function testShouldInstantiateAnEmptyCartWithId(): void
11     {
12         
13     }
14 }

El nombre del método comienza con el prefijo test y debe ser público. De este modo, phpunit sabe que es un método de test y lo recolecta cuando decide qué tests tiene que ejecutar.

Otra forma de indicarlo es mediante anotaciones, lo que deja más limpio el nombre del método:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo\Shop;
 5 
 6 use Phpunit\Framework\TestCase;
 7 
 8 class CartTest extends TestCase
 9 {
10     /** @test */
11     public function shouldInstantiateAnEmptyCartWithId(): void
12     {
13 
14     }
15 }

¿Es mejor uno que otro de los dos sistemas? No. Es una cuestión de preferencia personal o de equipo. Así que haz lo que más te guste o lo que te parezca más legible.

En cuanto al nombre del test, debería ser descriptivo de lo que se va a probar en él. Últimamente, mi forma de hacerlo es empezar todos los tests escribiendo “should” (debería) lo que te va enfocando hacia definir un comportamiento observable y concreto. En el ejemplo que acabamos de poner, el test dice que debería instanciarse un carro vacío con un id.

No hay problema en cambiar el nombre del test si creemos que se puede describir mejor el comportamiento probado, normalmente no va a afectar a nada a nivel técnico. Considéralo un refactor básico del mismo.

Si no tienes claro cómo expresar lo que estás testeando es posible que eso refleje que no sabes con precisión qué es lo que quieres testear, por lo que tal vez debas darle unas vueltas a tu objetivo y definirlo mejor.

Por otro lado, podrías estar en una fase exploratoria mientras tratas de comprender cómo funciona el software, por lo que puedes ponerle al test un nombre provisional como shouldDoSomething y cambiarlo cuando tengas más claras las cosas.

En nuestro ejemplo, vamos a hacer un poco más preciso el nombre del test:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo\Shop;
 5 
 6 use Phpunit\Framework\TestCase;
 7 
 8 class CartTest extends TestCase
 9 {
10     public function testShouldInstantiateAnEmptyCartIdentifiedWithAnId(): void
11     {
12         
13     }
14 }

Bien, es hora de empezar a poner código. Lo que va a hacer este test es instanciar un carro y comprobar que cumple las condiciones expresadas. Recuerda, de nuevo, que un test tiene tres partes principales:

El escenario (la parte Given o Arrange del test) es que el usuario va a tomar un carro nuevo, por lo tanto, no tiene productos preseleccionados.

La acción (When o Action del test) es crear un carro nuevo.

El resultado (Then o Assert del test) es que el carro tiene un identificador y que no contiene productos:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo\Shop;
 5 
 6 use Phpunit\Framework\TestCase;
 7 
 8 class CartTest extends TestCase
 9 {
10     public function testShouldInstantiateAnEmptyCartIdentifiedWithAnId(): void
11     {
12         $cart = Cart::pickUp();
13         
14         $this->assertNotEmpty($cart->id());
15         $this->assertEquals(0, $cart->totalProducts());
16     }
17 }

En este caso no necesitamos preparar nada previamente a obtener el carro.

La acción es el hecho de inicializar el carro. Puesto que tenemos un named constructor estático no tenemos más que asignar una variable $cart con Cart::pickUp().

Ahora $cart contiene un carrito nuevo. Lo que hacemos a continuación es verificar ciertas condiciones mediante el uso de Aserciones.

Las aserciones encapsulan una comparación entre lo que esperamos y lo que obtenemos, realizando otras operaciones internas de recogida de información que serán útiles para la batería de tests. phpunit ofrece una buena cantidad de aserciones. Las que hemos usado aquí son:

assertNotEmpty verifica si el parámetro que le pasamos, que resulta ser el id del carrito recién creado, no está vacío.

assertEquals que verifica si el valor esperado (primer parámetro) es igual al obtenido en la acción (segundo parámetro).

En este caso, si ambas aserciones se cumplen, el test pasa e indicaría que, efectivamente, nuestro carrito se instancia con un identificador y vacío de productos.

Y eso es lo que ocurre al ejecutar:

1 bin/phpunit Dojo\Shop\CartTest tests/Dojo/Shop/CartTest.php

Testeando la instanciación alternativa

La segunda forma de instanciar el carrito nos permite hacerlo añadiendo un producto previamente seleccionado por el usuario, para lo cual existe otro named constructor que admite parámetros que especifican el producto y la cantidad inicial del mismo.

Para probar esta segunda forma de instanciación lo que necesitamos es tener un producto, pasarlo al constructor y comprobar que el carrito contiene ese producto.

1 $cart = Cart::pickUpWithProduct($product, 1);

1 $id = $cart->id();
2 $numberOfProducts = $cart->count();

Nuestro escenario require que exista algún producto que podamos adquirir.

Nuestra acción será instanciar el carro con el método que nos permite pasarle el producto inicial.

Nuestra aserción será ver si se ha creado el id y si el producto ha sido añadido efectivamente al carro.

Algo así:

 1     public function testShouldInstantiateCartWithAPreselectedProduct(): void
 2     {
 3         $product = $this->getProduct('product-1', 10);
 4         $cart = Cart::pickUpWithProduct($product, 1);
 5 
 6         $this->assertNotEmpty($cart->id());
 7         $this->assertEquals(1, $cart->totalProducts());
 8     }
 9     
10     private function getProduct($id, $price): ProductInterface
11     {
12         //...
13     }

De momento, hemos encapsulado la creación del producto en un método porque precisamente queremos discutir de dónde vamos a sacarlo para el test.

Ahora mismo estamos escribiendo un test unitario, lo que implica que lo que estamos observando es el comportamiento de una unidad concreta de software (Cart) y queremos evitar la influencia de otras unidades que puedan intervenir en alguna de sus acciones.

En el test que estamos tratando ahora necesitaremos un objeto producto para pasarle inicialmente al carro. Tenemos varias formas de usar ese objeto:

• Utilizar una instancia cualquiera de la clase Product.
• Utilizar un doble de la clase Product. A su vez, el doble podemos obtenerlo creando una subclase de Product apta para test, o bien usar un doble creado con una alguna utilidad.

En nuestro ejemplo, tenemos una interfaz ProductInterface que implementan todas las clases Product de nuestra tienda online:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo\Shop;
 5 
 6 interface ProductInterface
 7 {
 8     public function id(): string;
 9 
10     public function price(): float;
11 }

ProductInterface nos garantiza que los objetos que le pasamos a Cart tengan un método id y un método price, que necesitamos para las operaciones propias de Cart.

Usando objetos reales

Podría ser que tuviésemos una clase Product que implementa esta interface:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo\Shop;
 5 
 6 class Product implements ProductInterface
 7 {
 8     /** @var string */
 9     private $id;
10     /** @var float */
11     private $price;
12 
13     public function __construct(string $id, float $price)
14     {
15         $this->id = $id;
16         $this->price = $price;
17     }
18 
19     public function id(): string
20     {
21         return $this->id;
22     }
23 
24     public function price(): float
25     {
26         return $this->price;
27     }
28 }

En consecuencia, simplemente podríamos crear un producto instanciando esa clase. Nuestro método getProduct, quedaría así;

1     private function getProduct($id, $price): ProductInterface
2     {
3         return new Product($id, $price);
4     }

La gran ventaja es que es fácil y obvio. Esto es aplicable a objetos sencillos que tienen poco o ningún comportamiento, al menos en lo que respecta a la acción que estamos testeando, lo que nos permite garantizar que ese comportamiento no influye en la acción que probamos.

El test, de hecho, pasará sin problemas.

Normalmente esta técnica es adecuada cuando el objeto que necesitamos es una entidad, un value object, un DTO o cualquier otro tipo de objeto que nos interesa fundamentalmente por sus datos y que no tiene un comportamiento que afecte realmente al del objeto que estamos testando.

Usando dobles

Sin embargo, podría ocurrir que el objeto que necesitamos para testear otro no sólo tenga comportamiento, sino que el comportamiento de nuestro objeto bajo test sea dependiente de él. En otras palabras, que sea un “colaborador”. En ese caso normalmente necesitaremos un doble en el que podamos definir con total precisión el comportamiento que va a exhibir en ese test concreto.

Además de controlar con exactitud el comportamiento del colaborador, puede ser que ese colaborador por su implementación sea lento o dependa de cuestiones fuera del ámbito del test, como puede ser acceso a servicios remotos que hacen no sólo incontrolable su respuesta, sino que no garantizan su disponibilidad en la situación de test o su uso podría interferir en el funcionamiento de un sistema en producción.

En ese caso, debemos crear “dobles” que representen a esos objetos necesarios con comportamientos que nosotros predefinimos. Para crear dobles podemos usar dos estrategias:

• Definir una clase que implemente la misma interfaz del colaborador o que extienda la clase, escribiendo métodos con un comportamiento nulo o prefijado para el test.
• Utilizar una utilidad para generar dobles como la que ofrece el propio phpunit, con la cual simularemos comportamientos específicos del colaborador.

La segunda opción es la más práctica ya que no tenemos que escribir una clase a propósito para el test, sino que simplemente simulamos sus comportamientos indicando que debería responder cada método al ser invocado.

En el test que nos ocupa no es necesario utilizar esta estrategia, pero podemos hacerlo. El método getProduct podría quedar así:

1     private function getProduct($id, $price): ProductInterface
2     {
3         /** @var ProductInterface | MockObject $product */
4         $product = $this->createMock(ProductInterface::class);
5         $product->method('id')->willReturn($id);
6         $product->method('price')->willReturn($price);
7         
8         return $product;
9     }

Brevemente:

$this->createMock(ProductInterface::class) devuelve un objeto que implementa la interfaz ProductInterface, aunque también podría generarse a partir de Product o de cualquier objeto que quisiésemos simular.

El objeto $product devuelto es tanto un ProductInterface como un MockObject, gracias a lo cual podemos simular el comportamiento realizado por sus métodos.

Con method le indicamos a $product que vamos a especificar el comportamiento de uno de sus métodos, forzándolo a devolver una respuesta prefijada mediante willReturn.

Por ejemplo, esto sería como tener un Product cuyo id es el especificado en $id.

1 $product->method('id')->willReturn($id);

En otro capítulo profundizaremos en la creación y uso de dobles de test.

Finalmente, si ejecutamos el test, comprobaremos que también pasa.

Testeando que podemos añadir productos al carro

Con lo anterior hemos verificado que podemos instanciar el carro y podemos tachar dos requisitos de nuestra lista. Nuestro objetivo ahora es probar que podemos añadir productos. En cierto modo ya sabemos que esto se cumple pues tenemos un test que muestra que es posible instanciar el carro añadiendo un producto. Además, si vemos el código podemos comprobar que internamente se llama al método que añade productos, lo que implica que el test existente prueba, indirectamente, el comportamiento que vamos a examinar ahora.

Sin embargo, cuando hacemos tests unitarios, deberíamos considerar la clase bajo test como una caja negra y no pensar en su implementación, sino en su comportamiento observable. Podría ocurrir que la forma de añadir productos al carro fuese distinta en la creación que durante el resto de su ciclo de vida, por lo que testear explícitamente el método para añadir productos es mucho más seguro.

En este caso tenemos varios escenarios ya que necesitamos probar varias cosas:

• Que podamos añadir una unidad de un producto.
• Que podamos añadir varias unidades del mismo producto.
• Que podamos añadir una unidad de más de un producto.
• Que podamos añadir varias unidades de más de un producto.

En realidad, por lo que podemos ver de la interfaz pública, podemos añadir de una sola vez un producto, variando la cantidad.

Así que realmente podríamos testear estas situaciones:

• Añadir una unidad de producto.
• Añadir más de una unidad de producto.
• Añadir una unidad de dos productos distintos.

Existen varias formas de testear que hemos añadido productos al carro. La más obvia sería obtener los productos que tiene el carro y comprobar que están los que hemos introducido y que veremos luego.

La otra forma es mucho más sencilla. Consiste simplemente en ver si la cantidad de productos en el carro es la que esperamos según los que hemos ido añadiendo. Si sólo añadimos un producto, debería haber sólo un producto o una sola línea de producto, que es lo que realmente nos dice el método count.

1 public function testShouldAddAProduct(): void
2 {
3     $product = $this->getProduct('product-1', 10);
4     $cart = Cart::pickUp();
5 
6     $cart->addProductInQuantity($product, 1);
7     
8     $this->assertCount(1, $cart);
9 }

Si queremos testear que podemos añadir una cantidad de productos mayor a uno, nos encontramos que no nos vale el mismo test. count nos dice cuántos productos distintos hay, mientras que totalProducts nos dice cuántas unidades de productos hay en total. Primero veremos el test y luego analizaremos algunas cosas interesantes:

 1 public function testShouldAddAProductInQuantity(): void
 2 {
 3     $product = $this->getProduct('product-1', 10);
 4     $cart = Cart::pickUp();
 5 
 6     $cart->addProductInQuantity($product, 10);
 7     
 8     $this->assertCount(1, $cart);
 9     $this->assertEquals(10, $cart->totalProducts());
10 }

Triangulación. En este test hacemos dos aserciones que verifican dos aspectos similares del mismo problema. Decimos que hacemos triangulación en un test precisamente cuando hacemos varias aserciones que por sí solas podrían tener una interpretación ambigua, mientras que si las hacemos juntas reflejan con precisión lo que queremos comprobar.

En este caso, añadir un producto en una cantidad distinta de uno implica que se añade una única línea de producto en el carrito, pero que éste contiene diez unidades en total. Si sólo comprobásemos que hay diez unidades, no sabríamos si se corresponden con una única línea o con cinco o diez, lo que sería incorrecto según cómo debería funcionar nuestro carrito de la compra.

Detección de problemas. Cuando estamos haciendo un test y lo que queremos testear nos hace dudar, habitualmente es señal de que hay algún punto mejorable en el código. De hecho, cualquier dificultad al testear nos podría estar dando pistas de un problema de diseño.

Por ejemplo, el significado de count como número de líneas o productos distintos en el carro no es muy intuitivo. Si count devolviese el número de productos en total dentro del carro seguramente nos parecería más natural. La interfaz de Cart podría quedar así:

• Cart::count(): número de productos
• Cart::totalLines(): número de líneas

El tercer test relacionado con añadir productos al carro sería uno en el que añadimos varios productos en distintas cantidades. Eso generará una línea por cada producto distinto y hará que el total de productos sea la suma de las cantidades.

 1 public function testShouldAddSeveralProductsInQuantity(): void
 2 {
 3     $product1 = $this->getProduct('product-1', 10);
 4     $product2 = $this->getProduct('product-2', 15);
 5     
 6     $cart = Cart::pickUp();
 7 
 8     $cart->addProductInQuantity($product1, 5);
 9     $cart->addProductInQuantity($product2, 7);
10 
11     $this->assertCount(2, $cart);
12     $this->assertEquals(12, $cart->totalProducts());
13 }

De nuevo hemos aplicado triangulación, ya que queremos que no haya ambigüedad al interpretar lo que ocurre aquí.

Esto nos lleva a otra cuestión: ¿qué ocurre si añado productos de un tipo, luego de otro y luego del primer tipo? Deberían generarse dos líneas de productos, no tres. Y debería acumularse el total de unidades. Probémoslo:

 1 public function testShouldAddSameProductsInDifferentMoments(): void
 2 {
 3     $product1 = $this->getProduct('product-1', 10);
 4     $product2 = $this->getProduct('product-2', 15);
 5 
 6     $cart = Cart::pickUp();
 7 
 8     $cart->addProductInQuantity($product1, 5);
 9     $cart->addProductInQuantity($product2, 7);
10     $cart->addProductInQuantity($product2, 3);
11 
12     $this->assertCount(2, $cart);
13     $this->assertEquals(15, $cart->totalProducts());
14 }

Y este test falla. De nuevo, la triangulación resulta importante. Si sólo hiciésemos una aserción sobre el número de líneas, el test pasaría:

 1 public function testShouldAddSameProductsInDifferentMoments(): void
 2 {
 3     $product1 = $this->getProduct('product-1', 10);
 4     $product2 = $this->getProduct('product-2', 15);
 5 
 6     $cart = Cart::pickUp();
 7 
 8     $cart->addProductInQuantity($product1, 5);
 9     $cart->addProductInQuantity($product2, 7);
10     $cart->addProductInQuantity($product2, 3);
11 
12     $this->assertCount(2, $cart);
13 }

Y esto nos daría una visión engañosa de lo que hace el código. Por eso, es importante definir bien lo que estamos testeando y cómo lo vamos a observar o medir.

Detección de errores. Por otro lado, este ejercicio nos revela el poder del testing para detectar bugs que no son aparentes o que se manifiestan sólo en ciertos casos de uso. Un vistazo rápido al código podría no revelar ningún problema y, por otro lado, el caso de uso de que un usuario añade un producto y, más tarde, añade más unidades de ese producto puede no ser evidente a primera vista.

En cualquier caso, lo que nos dice el resultado del test es que debemos modificar el código para hacerlo pasar. En este ejemplo, nos dice que al añadir un producto tendríamos que comprobar si ya estaba en el carrito y añadir las unidades extra.

 1 private function addCartLine(Cartline $cartLine): void
 2 {
 3     $product = $cartLine->product();
 4     
 5     if (! isset($this->lines[$product->id()])) {
 6         $this->lines[$product->id()] = $cartLine;
 7 
 8         return;
 9     }
10     
11     $newCartLine = new CartLine(
12         $product,
13         $cartLine->quantity() + $this->lines[$product->id()]->quantity()
14     );
15 
16     $this->lines[$product->id()] = $newCartLine;
17 }

Con este código el test pasa y la prestación de añadir productos al carro está ahora correctamente implementada.

Redundancia de tests

Con los tests que hemos escrito hasta ahora hemos cubierto dos de los comportamientos más importantes del carrito:

• Que el usuario pueda tomar un carrito e iniciar las compras
• Que pueda añadir objetos al carrito

Para poder verificar esos comportamientos hemos tenido que recurrir a algunos métodos que nos proporcionan recuentos del contenido del carrito. Estos métodos, por su parte, estaban en la lista de requisitos con la que habíamos empezado a trabajar.

La cuestión es que esos métodos no han sido testeados explícitamente, sino que los hemos verificado de forma implícita en los tests que hemos escrito para comprobar el comportamiento de la clase.

La pregunta que surge aquí es si deberíamos tener tests que los prueben explícitamente o no.

La respuesta es una cuestión de enfoque:

En un enfoque orientado al comportamiento tendríamos suficiente con los tests que ya hemos realizado. Los métodos de recuento ya están cubiertos implícitamente y la información que pueda aportar tests específicos sería redundantes. Al fin y al cabo estos métodos simplemente recogen datos del estado del objeto al realizar sus comportamientos.

En el enfoque alternativo, los tests específicos de estos métodos serían necesarios para eliminar cualquier ambigüedad y poder diagnosticar de forma precisa en caso de problemas. Puede resultar difícil aislar estos métodos para que los tests no resulten redundantes y se limiten a probar lo mismo que ya está probado en otros.

La redundancia en los tests no suele merecer la pena per se ya que no aporta nueva información. Es lo que ocurre en el ejemplo que tenemos entre manos, los tests de los métodos de recuento no nos van a proporcionar una información diferente de la que ya tenemos.

Otros tests

Uno de los comportamientos que se espera de Cart es darnos información sobre el importe total de los productos en el carrito, que obtenemos mediante el método amount. Una buena idea es empezar con un caso extremo y asegurarnos de que un carro vacío cuesta cero, lo que garantizará que no se han introducido importes inesperados al crear el carro.

1 public function testEmptyCartShouldHaveZeroAmount(): void
2 {
3     $cart = Cart::pickUp();
4 
5     $this->assertEquals(0, $cart->amount());
6 }

Obviamente, a continuación deberíamos testear que se contabilizan los precios de los productos que añadimos.

1 public function testShouldCalculateAmountWhenAddingProduct(): void
2 {
3     $cart = Cart::pickUp();
4 
5     $product = $this->getProduct('product-01', 10);
6     $cart->addProductInQuantity($product, 1);
7 
8     $this->assertEquals(10, $cart->amount());
9 }

Así como que tiene en cuenta las cantidades.

1 public function testShouldTakeCareOfQuantitiesToCalculateAmount(): void
2 {
3     $cart = Cart::pickUp();
4 
5     $product = $this->getProduct('product-01', 10);
6     $cart->addProductInQuantity($product, 3);
7 
8     $this->assertEquals(30, $cart->amount());
9 }

Y que podemos combinar productos y cantidades:

 1 public function testShouldTakeCareOfQuantitiesAndDifferentProductsToCalculateAmount(\
 2 ): void
 3 {
 4     $cart = Cart::pickUp();
 5 
 6     $product1 = $this->getProduct('product-01', 10);
 7     $product2 = $this->getProduct('product-02', 7);
 8     
 9     $cart->addProductInQuantity($product1, 3);
10     $cart->addProductInQuantity($product2, 4);
11 
12     $this->assertEquals(58, $cart->amount());
13 }

Descubriendo implementaciones incorrectas

En la lista de requisitos se nos dice que debemos poder retirar productos del carro, decrementando su cantidad. Si pensamos en los posibles escenarios veremos que son tres:

• El carro no tiene el producto previamente, por lo que no hay nada que decrementar.
• El carro tiene una unidad del producto, así que debería retirarse sin problema, quedando el carro con ninguna unidad de ese producto.
• El carro tiene más de unidad del producto (n), por lo que debería retirarse una sin problemas, lo que se reflejaría en que quedan n-1 en el carro.

Así que planteamos los tests correspondientes:

El método removeProduct lanzará una excepción si no tenemos el producto indicado. Podemos testear fácilmente que se lanzan excepciones mediante el método expectException del TestCase de phpunit.

1 public function testShouldFailRemovingNonExistingProduct() : void
2 {
3     $cart = Cart::pickUp();
4 
5     $product = $this->getProduct('product-1', 10);
6 
7     $this->expectException(UnderflowException::class);
8     $cart->removeProduct($product);
9 }

Este test pasa, lo que indica que este requisito está bien implementado.

Veamos el segundo. Primero ponemos un producto en el carro y luego lo retiramos, comprobando si queda alguno:

 1 public function testShouldLeaveNoProductWhenRemovingTheLastOne(): void
 2 {
 3     $cart = Cart::pickUp();
 4 
 5     $product = $this->getProduct('product-1', 10);
 6 
 7     $cart->addProductInQuantity($product, 1);
 8     $cart->removeProduct($product);
 9 
10     $this->assertEquals(0, $cart->count());
11 }

Este test también pasa. Si dejásemos de hacer tests aquí podríamos decir que el requisito se cumple y que la feature está implementada. Es por esa razón que hemos definido los tres escenarios: carro vacío, carro con un único producto y carro con más de una unidad del producto.

En nuestro ejemplo se puede prever que el tercer test no pasará tal y como está implementado el método. Sin embargo, es muy posible que el código real que tienes que testear no sea tan fácil de leer y la única manera de asegurarte de que funciona como es debido es precisamente haciendo un test que lo verifique.

Lo probaremos añadiendo dos productos y quitando uno de ellos. El carro debería contener todavía un producto:

 1 public function testShouldLeaveOneProduct(): void
 2 {
 3     $cart = Cart::pickUp();
 4 
 5     $product = $this->getProduct('product-1', 10);
 6 
 7     $cart->addProductInQuantity($product, 2);
 8     $cart->removeProduct($product);
 9 
10     $this->assertEquals(1, $cart->count());
11 }

Pero no ocurre eso, si no que se eliminan todas las unidades del mismo producto, lo que demuestra que la feature no está implementada correctamente.

He aquí una implementación sencilla que hace pasar el test, corrigiendo el problema:

 1 public function removeProduct(ProductInterface $product): void
 2 {
 3     if (!isset($this->lines[$product->id()])) {
 4         throw new UnderflowException(
 5             sprintf('Product %s not in this cart', $product->id())
 6         );
 7     }
 8 
 9     $line = $this->lines[$product->id()];
10 
11     $newQuantity = $line->quantity() - 1;
12 
13     $this->lines[$product->id()] = new CartLine($product, $newQuantity);
14 }

En resumen. Es muy importante definir bien los escenarios que debemos probar en los tests, para lo que podemos utilizar las distintas técnicas de análisis que comentamos en un capítulo anterior, a fin de asegurarnos de que implementamos las features que se nos ha pedido de forma correcta.

Últimos tests

Tenemos pendiente el test de que podemos vaciar por completo el carro, el cual podría quedar así:

 1 public function testShouldEmptyTheCart() : void
 2 {
 3     $cart = Cart::pickUp();
 4 
 5     $product = $this->getProduct('product-1', 10);
 6     $cart->addProductInQuantity($product, 2);
 7 
 8     $cart->drop();
 9     
10     $this->assertEmpty($cart);
11 }

Nos queda por crear un test sobre si podemos preguntarle al carro explícitamente si está vacío, lo que supone la existencia de un método isEmpty o similar. Este test implica que debemos probar tanto que el caso positivo (está vacío):

1 public function testShouldReportIsEmpty() : void
2 {
3     $cart = Cart::pickUp();
4     
5     $this->assertTrue($cart->isEmpty());
6 }

Como el negativo (contiene algún producto):

1 public function testShouldReportIsNotEmpty() : void
2 {
3     $cart = Cart::pickUp();
4     
5     $product = $this->getProduct('product-1', 10);
6     $cart->addProductInQuantity($product, 2);
7     
8     $this->assertFalse($cart->isEmpty());
9 }

Hemos terminado… de momento

Este es el TestCase con el que hemos probado que Cart funciona, o en algunos casos no lo hace como se desea:

  1 <?php
  2 declare(strict_types=1);
  3 
  4 namespace Dojo\Shop;
  5 
  6 use Phpunit\Framework\MockObject\MockObject;
  7 use Phpunit\Framework\TestCase;
  8 use UnderflowException;
  9 
 10 class CartTest extends TestCase
 11 {
 12     public function testShouldInstantiateAnEmptyCartIdentifiedWithAnId(): void
 13     {
 14         $cart = Cart::pickUp();
 15 
 16         $this->assertNotEmpty($cart->id());
 17         $this->assertEquals(0, $cart->totalProducts());
 18     }
 19 
 20     public function testShouldInstantiateCartWithAPreselectedProduct(): void
 21     {
 22         $product = $this->getProduct('product-1', 10);
 23         $cart = Cart::pickUpWithProduct($product, 1);
 24 
 25         $this->assertNotEmpty($cart->id());
 26         $this->assertEquals(1, $cart->totalProducts());
 27     }
 28 
 29     public function testShouldAddAProduct(): void
 30     {
 31         $product = $this->getProduct('product-1', 10);
 32         $cart = Cart::pickUp();
 33 
 34         $cart->addProductInQuantity($product, 1);
 35         $this->assertCount(1, $cart);
 36     }
 37 
 38     public function testShouldAddAProductInQuantity(): void
 39     {
 40         $product = $this->getProduct('product-1', 10);
 41         $cart = Cart::pickUp();
 42 
 43         $cart->addProductInQuantity($product, 10);
 44         $this->assertCount(1, $cart);
 45         $this->assertEquals(10, $cart->totalProducts());
 46     }
 47 
 48     public function testShouldAddSeveralProductsInQuantity(): void
 49     {
 50         $product1 = $this->getProduct('product-1', 10);
 51         $product2 = $this->getProduct('product-2', 15);
 52         $cart = Cart::pickUp();
 53 
 54         $cart->addProductInQuantity($product1, 5);
 55         $cart->addProductInQuantity($product2, 7);
 56 
 57         $this->assertCount(2, $cart);
 58         $this->assertEquals(12, $cart->totalProducts());
 59     }
 60 
 61     public function testShouldAddSameProductsInDifferentMoments(): void
 62     {
 63         $product1 = $this->getProduct('product-1', 10);
 64         $product2 = $this->getProduct('product-2', 15);
 65 
 66         $cart = Cart::pickUp();
 67 
 68         $cart->addProductInQuantity($product1, 5);
 69         $cart->addProductInQuantity($product2, 7);
 70         $cart->addProductInQuantity($product2, 3);
 71 
 72         $this->assertCount(2, $cart);
 73         $this->assertEquals(15, $cart->totalProducts());
 74     }
 75 
 76     public function testEmptyCartShouldHaveZeroAmount(): void
 77     {
 78         $cart = Cart::pickUp();
 79 
 80         $this->assertEquals(0, $cart->amount());
 81     }
 82 
 83     public function testShouldCalculateAmountWhenAddingProduct(): void
 84     {
 85         $cart = Cart::pickUp();
 86 
 87         $product = $this->getProduct('product-01', 10);
 88         $cart->addProductInQuantity($product, 1);
 89 
 90         $this->assertEquals(10, $cart->amount());
 91     }
 92 
 93     public function testShouldTakeCareOfQuantitiesToCalculateAmount(): void
 94     {
 95         $cart = Cart::pickUp();
 96 
 97         $product = $this->getProduct('product-01', 10);
 98         $cart->addProductInQuantity($product, 3);
 99 
100         $this->assertEquals(30, $cart->amount());
101     }
102 
103     public function testShouldTakeCareOfQuantitiesAndDifferentProductsToCalculateAmo\
104 unt(): void
105     {
106         $cart = Cart::pickUp();
107 
108         $product1 = $this->getProduct('product-01', 10);
109         $product2 = $this->getProduct('product-02x', 7);
110 
111         $cart->addProductInQuantity($product1, 3);
112         $cart->addProductInQuantity($product2, 4);
113 
114         $this->assertEquals(58, $cart->amount());
115     }
116 
117     public function testShouldFailRemovingNonExistingProduct() : void
118     {
119         $cart = Cart::pickUp();
120 
121         $product = $this->getProduct('product-1', 10);
122 
123         $this->expectException(UnderflowException::class);
124         $cart->removeProduct($product);
125     }
126 
127     public function testShouldLeaveNoProductWhenRemovingTheLastOne(): void
128     {
129         $cart = Cart::pickUp();
130 
131         $product = $this->getProduct('product-1', 10);
132 
133         $cart->addProductInQuantity($product, 1);
134         $cart->removeProduct($product);
135 
136         $this->assertEquals(0, $cart->count());
137     }
138 
139     public function testShouldLeaveOneProduct(): void
140     {
141         $cart = Cart::pickUp();
142 
143         $product = $this->getProduct('product-1', 10);
144 
145         $cart->addProductInQuantity($product, 2);
146         $cart->removeProduct($product);
147 
148         $this->assertEquals(1, $cart->count());
149     }
150 
151     public function testShouldEmptyTheCart() : void
152     {
153         $cart = Cart::pickUp();
154 
155         $product = $this->getProduct('product-1', 10);
156         $cart->addProductInQuantity($product, 2);
157 
158         $cart->drop();
159 
160         $this->assertEmpty($cart);
161     }
162 
163     public function testShouldReportIsEmpty() : void
164     {
165         $cart = Cart::pickUp();
166 
167         $this->assertTrue($cart->isEmpty());
168     }
169 
170     public function testShouldReportIsNotEmpty() : void
171     {
172         $cart = Cart::pickUp();
173 
174         $product = $this->getProduct('product-1', 10);
175         $cart->addProductInQuantity($product, 2);
176 
177         $this->assertFalse($cart->isEmpty());
178     }
179 
180     private function getProduct(
181         $id,
182         $price
183     ): ProductInterface {
184         /** @var ProductInterface | MockObject $product */
185         $product = $this->createMock(ProductInterface::class);
186         $product->method('id')->willReturn($id);
187         $product->method('price')->willReturn($price);
188 
189         return $product;
190     }
191 }

¿Cómo seguir a partir de ahora? Al tener el código de Cart bajo test ganamos varias cosas:

Podemos hablar con propiedad de lo que hace Cart. El primer beneficio de tener el software cubierto con tests es justamente que ahora tenemos una definición concreta y reproducible de lo que Cart hace y cuáles son sus límites. Cualquier afirmación que podamos hacer sobre su comportamiento o bien está demostrada por un test, o bien podemos hacer un test para demostrarla.

Por ejemplo, si ocurre algún tipo de bug, podemos crear un nuevo test que al poner en evidencia el error nos indique dónde tenemos que intervenir y cuál es el resultado que debemos lograr. Por otro lado, el test podría demostrar que el error no es causado por Cart, sino por otro elemento del código.

Refactor: podemos cambiar Cart sin riesgo. Otro beneficio es que podemos modificar la implementación de Cart con la seguridad de que no romperemos su comportamiento. Mientras los tests sigan pasando podemos hacer todos los cambios que nos lleven a una mejor arquitectura.

Si lo que necesitamos es una reescritura los tests nos servirán para hacerlo con seguridad, aunque quizá tengamos que retocarlos para responder a las nuevas decisiones de diseño.

Un ejercicio para aprender TDD

Una vez que comprendemos el concepto, no es difícil hacer TDD. Pero ese primer paso necesario para arrancar suele necesitar ayuda. Lo mejor es encontrar un ejercicio de programación que sea sencillo sin ser trivial y que ayude a poner de manifiesto los elementos más importantes de la metodología TDD.

TDD es más una disciplina que una técnica específica. Para aprender y mejorar en ella lo recomendable es practicar mucho. Los ejercicios de TDD suelen denominarse katas, como las de las artes marciales. Se trata de automatizar el proceso de crear un test, escribir código para que el test pase y refactorizar. Por eso, conviene hacer y repetir ejercicios, ya sea en solitario, ya sea en pairing con otra persona, o en grupo, o incluso presenciar cómo lo hacen otras personas.

Recientemente, encontré un ejercicio que me ha ido muy bien para empezar a introducir a otras personas en TDD. Aunque no es una kata reconocida, he descubierto que funciona muy bien como primera aproximación a la metodología. Se trata de escribir un Value Object para representar el DNI (el documento de identificación individual en España). Ese documento también se utiliza como Número de Identificación Fiscal (NIF) por lo que usaré los dos nombres indistintamente.

Repasando conceptos

Qué es eso del DNI (si no eres de España)

Un DNI (Documento Nacional de Identidad) es un identificador que consta de ocho cifras numéricas y una letra que actúa como dígito de control. Existen algunos casos particulares en los que el primer número se sustituye por una letra y ésta, a su vez, por un número para el cómputo de validez que viene a continuación. Este último es el caso del NIE o Número de Identificación para Extranjeros residentes.

El algoritmo para validar un DNI es muy sencillo: se toma la parte del numero del documento y se divide entre 23 y se obtiene el resto. Ese resto es un índice que se consulta en una tabla de letras. La letra correspondiente al índice es la que debería tener un DNI válido. Por tanto, si la letra del DNI concuerda con la que hemos obtenido, es que es válido.

La tabla en cuestión es esta:

Qué es un Value Object

Value Object es un tipo de objeto que representa un concepto importante de un dominio el cual nos interesa por su valor, y no por su identidad. Esto quiere decir que dos Value Object del mismo tipo se consideran iguales e intercambiables si representan el mismo valor.

En el mundo físico tenemos un gran ejemplo de Value Object: el dinero. Los billetes de 10 euros, por ejemplo, representan todos la misma cantidad, y da igual el ejemplar concreto que tengamos, siempre representará 10 euros y lo podremos cambiar por otro del mismo valor, o por una combinación de billetes y monedas que sumen el mismo valor. Los billetes, de hecho, tienen una identidad (se les asigna un número de serie) pero no se tiene en cuenta para su utilización como medio de pago.

El valor representado por un billete no cambia. En el ámbito de la programación, los Value Objects tampoco pueden cambiar de valor a lo largo de su ciclo de vida: son inmutables. Se instancian con un valor determinado que no puede cambiarse. Para tener un valor nuevo se debe instanciar un objeto nuevo de ese tipo con el nuevo valor.

Para instanciar un Value Object debemos asegurarnos de que los valores que le pasamos nos permiten hacerlo de forma consistente, por lo que serán importantes las validaciones. Lo bueno, es que una vez creado, siempre podemos confiar en que ese Value Object será válido y lo podemos usar sin ningún problema.

Las leyes de TDD

Repasemos las leyes de TDD. Son tres, en la formulación de Robert C. Martin:

• No escribirás ningún código de producción sin antes tener un test que falle.
• No escribirás nada más que un test unitario que sea suficiente para fallar.
• No escribirás nada más que el código de producción necesario para hacer pasar el test.

La primera regla nos dice que siempre hemos de empezar con un test. El test especifica lo que queremos conseguir que haga el código de producción que escribiremos posteriormente. Nos indica un objetivo en el que nos vamos a centrar durante los minutos siguientes, sin preocuparnos de nada más.

La segunda regla nos pide que sólo escribamos un único test cada vez y que sea lo bastante concreto como para fallar por un motivo específico, y lo hará inicialmente orque todavía no hemos escrito código que resuelva esa situación que estamos definiendo con el test.

Una vez que tenemos el test tenemos que ejecutarlo y verlo fallar. Literalmente: “verlo fallar”. No basta con “saber” que va a fallar. Tenemos que verlo fallar y que, así, nos diga cosas.

La tercera regla nos pide que al escribir el código de producción nos limitemos al estrictamente necesario para hacer pasar el test, ni más, ni menos, de la manera más inmediata y obvia posible en las condiciones actuales del código.

Si la manera más obvia es devolver la respuesta esperada por el test, eso es lo que debemos hacer.

Si la manera más obvia es tratar un caso con una estructura if… else, y devolver algo distinto en cada rama, eso es lo que debemos hacer.

Ya vendrán después otros tests que nos forzarán a cambiar esa implementación obvia por una más general.

Estas tres leyes son las fuerzas motoras del desarrollo dirigido por tests o TDD y, a pesar de su aparente sencillez, tienen una gran potencia para ayudarnos a escribir un código eficiente y bien diseñado.

Y espero que en este ejercicio las puedas ver en acción.

La kata del DNI

Nuestro ejercicio consistirá en crear un Value Object que nos sirva para representar un DNI o NIF. Por tanto, queremos que se pueda instanciar un objeto sólo si tenemos un DNI válido. Así que vamos a ello.

Lo que queremos es algo así:

1 $validDni = new Dni('00000000T');
2 
3 printf('%s is a valid DNI', (string) $validDni);
4 
5 //
6 
7 $invalidDni = new Dni('00000000G');
8 
9 >>> Throws Exception

¿Qué vamos a testear?

Esencialmente, un DNI no es más que una cadena de caracteres con un formato específico. De todas las cadenas de caracteres que se podrían generar sólo un subconjunto de ellas cumplen todas las condiciones exigidas para ser un DNI. Estas condiciones se pueden resumir en:

• Son cadenas de 9 caracteres.
• Los primeros 8 caracteres son números, y el último es una letra.
• La letra puede ser cualquiera, excepto U, I, O y Ñ.
• La última letra se obtiene a partir de un algoritmo que la consulta de una tabla a partir de obtener el resto de dividir la suma de los dígitos numéricos entre 23. Si la letra suministrada no se corresponde con la calculada, el DNI no es válido.
• El primer carácter puede ser X, Y o Z, lo que indica un NIE (Número de identificación para personas extranjeras).
• Para la validación, las letras XYZ se reemplazan por 0, 1 ó 2, respectivamente.

En caso de que alguna de las condiciones no se cumpla, el DNI no es válido.

Si nos fijamos en las condiciones recogidas en la lista anterior, vemos que cada una de ellas reduce el número de cadenas de caracteres candidatas a ser un DNI.

El primer test

Una de las grandes ventajas de trabajar con TDD es que nos permite posponer la toma de decisiones sobre lo que programamos. Es una ventaja muy valiosa, aunque poco conocida. Precisamente esta kata del DNI lo refleja muy bien.

La capacidad de posponer decisiones es muy importante para escribir código de calidad. Nos permite ganar tiempo y conocimiento para tomar una decisión mejor informada. Así, en lugar de intentar decidir de entrada cómo vamos a implementar el algoritmo que valida los DNI, lo que vamos a hacer es posponerlo hasta estar en mejores condiciones de afrontarlo.

En primer lugar, vamos a buscar un problema lo más sencillo posible y lo vamos a resolver de la manera más obvia que podamos. Con lo que aprendamos, buscaremos un nuevo problema sencillo que nos acerque, poco a poco, al meollo del ejercicio: implementar la validación.

Un buen enfoque es tratar de empezar con un aspecto muy general de lo que vamos a desarrollar, para ir enfocándonos en detalles más concretos a medida que progresamos.

El primer problema sencillo que podemos resolver es asegurarnos de que vamos a rechazar cadenas de caracteres que de ningún modo pueden ser un DNI: aquellas que tienen más o menos de 9 caracteres.

Así que es hora de abrir el editor y empezar a escribir nuestro primer test.

El primer impulso podría ser el hacer un test con el que se compruebe que nuestro DNI sólo acepta cadenas que contengan exactamente nueve caracteres. Pero, si lo piensas, es mucho más fácil comprobar que rechaza cadenas que contengan más o menos de ese número caracteres.

Ten en cuenta lo siguiente: una vez que has hecho un test, tiene que seguir pasando a medida que añades más tests y más código de producción. Ahora mismo, podríamos escribir un test que prueba que una cadena de nueve caracteres sea aceptada, pero para que ese test no falle en el futuro, la cadena ya tendría que ser un DNI válido y nuestro código todavía no sabe nada sobre eso. Si ahora ponemos una cadena de nueve caracteres en el test que no sea un DNI válido, el test fallará en el futuro cuando implementemos el algoritmo completo, obligándonos a cambiar esos tests que han fallado.

Por eso, vamos a escoger un problema mucho más sencillo y general: rechazar cadenas de caracteres que no tengan la longitud adecuada y que, por tanto, nunca podrían ser DNI válidos, con lo que esos tests no fallarán al implementar el algoritmo completo. De hecho, sólo podrían fallar si realizamos algún cambio que introduzca un cambio en el comportamiento o un error, lo que los convierte en tests de regresión.

Por tanto, testearemos que al intentar instanciar un objeto Dni se lanza una excepción si la cadena de caracteres tiene una longitud inadecuada. Pero la vamos a hacer en dos pasos: primero probaremos cadenas con más de nueve caracteres.

y aquí tenemos el primer test, en tests/DniTest.php

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Tests\Dojo;
 5 
 6 use Dojo\Dni;
 7 use LengthException;
 8 use PHPUnit\Framework\TestCase;
 9 
10 class DniTest extends TestCase
11 {
12     public function testShouldFailWhenDniLongerThanMaxLenght()
13     {
14         $this->expectException(LengthException::class);
15         $this->expectExceptionMessage('Too long');
16         $dni = new Dni('0123456789');
17     }
18 }

Si lanzamos el test este es el resultado:

1 Failed asserting that exception of type "Error" matches expected exception "LengthEx\
2 ception". Message was: "Class 'Dojo\Dni' not found" at
3 /Users/franiglesias/PhpstormProjects/dojo/tests/Dojo/DniTest.php:16.

Este es el fallo que cabría esperar ya que no tenemos la clase Dni definida. Es la primera ley de TDD: no escribir código de producción sin antes tener un test que falle.

Pero esto ya nos dice lo que tenemos que hacer. Nuestro objetivo inmediato es crear la clase, simplemente para que el test pueda usarla.

Y la creamos rápidamente con ayuda del IDE (en src/Dni.php):

1 <?php
2 declare(strict_types=1);
3 
4 namespace Dojo;
5 
6 class Dni
7 {
8 
9 }

Ahora que hemos creado lo que el test nos pedía, podemos volver a lanzarlo y ver qué pasa. Y lo que pasa es esto:

1 Failed asserting that exception of type "LengthException" is thrown.

Hemos resuelto el primer error y el test ya se ejecuta y falla. Ahora ya estamos cumpliendo la segunda ley: tenemos el código de test mínimo para que falle. Y esto nos comunica, de nuevo, qué es lo que tenemos que hacer.

Y, en aplicación de la tercera ley, vamos a escribir el código de producción mínimo para hacer que el test pase.

Y lo mínimo, y más obvio, es hacer que la excepción se lance incondicionalmente:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     public function __construct()
11     {
12         throw new LengthException('Too long');
13     }
14 }

Este código de producción hace que el test pase y nosotros ya estamos listos para avanzar un paso más. Pero vamos a observar un par de detalles:

• No estamos pasando nada al constructor. De hecho, no lo necesitamos todavía. Estamos posponiendo la decisión de qué vamos a hacer con ese parámetro.
• El código sólo hace lo que pide el único test que tenemos, porque realmente no estamos resolviendo aún ese problema.

Y está bien que sea así.

El siguiente test

Ahora vamos a asegurarnos de que no podemos instanciar un objeto Dni con una cadena de longitud más corta que nueve caracteres. Por tanto, lo vamos a expresar mediante un nuevo test.

1 public function testShouldFailWhenDniShorterThanMinLenght(): void
2 {
3     $this->expectException(LengthException::class);
4     $this->expectExceptionMessage('Too short');
5     $dni = new Dni('01234567');
6 }

Si ahora lanzamos el test veremos que falla. Hemos decidido que se lanza el mismo tipo de excepción, pero con distinto mensaje.

1 Failed asserting that exception message 'Too long' contains 'Too short'.

Por tanto, nuestro objetivo ahora es hacer que el nuevo test pase, a la vez que mantenemos en verde el test anterior.

Si ahora escribiésemos el siguiente código de producción:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     public function __construct()
11     {
12         throw new LengthException('Too short');
13     }
14 }

Lo que ocurrirá será que el último test pasará, pero el anterior fallará. Ejecutando phpunit con la opción --testdox para verlo mejor: bin/phpunit tests/Dojo/DniTest.php --testdox obtenemos este informe:

1 s\Dojo\Dni
2  [ ] Should fail when dni longer than max lenght
3  [x] Should fail when dni shorter than min lenght

Es decir, que tenemos que resolver el problema planteado por el test anterior primero y luego aplicar la implementación obvia.

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     public function __construct(string $dni)
11     {
12         if (strlen($dni) > 9) {
13             throw new LengthException('Too long');
14         }
15         throw new LengthException('Too short');
16     }
17 }

Y ahora pasan los dos tests.

Este segundo test nos ha forzado a encontrar una solución al problema planteado en el test anterior. Es decir, al implementar el código obvio para pasar el test previo, hemos pospuesto la toma de decisiones sobre esa condición. Y es ahora cuando resolvemos el problema.

De hecho, estamos posponiendo el problema planteado para este segundo test, así que tenemos que avanzar y crear un nuevo test.

Tercer test

Ahora ya garantizamos que sólo serán candidatas a ser un Dni las cadenas de nueve caracteres y tenemos dos tests que lo demuestran.

Con eso hemos reducido el ámbito del problema. Ahora tenemos que ver qué secuencias de caracteres tienen aspecto de ser un DNI.

En realidad, sabemos que un DNI es una serie de números con una letra al final, excepto aquellos casos en los que se permiten ciertas letras como primer carácter. Esto nos dice que una cadena formada por números que tenga una letra al final puede ser un Dni. Pero, aún mejor, también nos dice que una cadena cuyo símbolo final sea un número no puede serlo, como una cadena formada sólo por números.

Por lo tanto, vamos a testear precisamente eso:

1 public function testShouldFailWhenDniEndsWithANumber(): void
2 {
3     $this->expectException(DomainException::class);
4     $this->expectExceptionMessage('Ends with number');
5     $dni = new Dni('012345678');
6 }

El mensaje que obtenemos al ejecutar el test nos dice lo que necesitamos saber:

1 Failed asserting that exception of type "LengthException" matches expected exception\
2  "DomainException". Message was: "Too short" at
3 /Users/franiglesias/PhpstormProjects/dojo/src/Dni.php:15
4 /Users/franiglesias/PhpstormProjects/dojo/tests/Dojo/DniTest.php:31
5 .

Y lo que nos está diciendo es que espera una excepción DomainException pero el código lanza una LengthException, indicándonos que tenemos un problema pendiente de resolver. Para ello, escribimos este código de producción:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     public function __construct(string $dni)
11     {
12         if (\strlen($dni) > 9) {
13             throw new LengthException('Too long');
14         }
15         if (\strlen($dni) < 9) {
16             throw new LengthException('Too short');
17         }
18 
19         throw new \DomainException('Ends with number');
20     }
21 }

Los tres test ahora pasan y es hora de analizar lo que tenemos.

El ciclo red-green-refactor

Hasta ahora, hemos estado siguiendo las leyes de TDD para guiar nuestros pasos, pero en el proceso TDD también se genera el ciclo red-green-refactor.

Este ciclo es consecuencia de las tres leyes:

• Fase red: una vez que tenemos un test que falla decimos que estamos en “rojo”, esto es: el test falla y tenemos que implementar código de producción para que pase.
• Fase green: nuestro objetivo es que el test pase y ponernos en “verde”.
• Fase refactor: una vez que hemos conseguido hacer pasar un test y antes de empezar a escribir el siguiente, examinamos nuestro código para ver si podemos aplicar alguna mejora mientras mantenemos los tests pasando.

Esto es: podemos mejorar la estructura y organización interna de nuestro código siempre que mantengamos su comportamiento, cosa que garantizamos mediante los tests. Si en este punto introducimos un cambio de comportamiento alguno de los tests fallará.

¿Qué cambios podríamos querer hacer? Lo más evidente suele ser evitar o reducir la duplicación innecesaria de código, lo que nos lleva poco a poco a mejores estructuras y diseños.

Vamos a ver qué encontramos en nuestro código de producción:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     public function __construct(string $dni)
11     {
12         if (\strlen($dni) > 9) {
13             throw new LengthException('Too long');
14         }
15         if (\strlen($dni) < 9) {
16             throw new LengthException('Too short');
17         }
18 
19         throw new \DomainException('Ends with number');
20     }
21 }

Para empezar, vemos el número nueve dos veces. No sólo hay una repetición del mismo valor, sino que lo podemos considerar un número mágico. Un número o valor mágico no es más que un valor arbitrario que tiene un significado no expresado en el código. En este caso, el nueve representa la longitud válida de un DNI, por lo que podríamos convertirlo en una constante, lo que le da nombre y significado:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         if (\strlen($dni) > self::VALID_LENGTH) {
15             throw new LengthException('Too long');
16         }
17         if (\strlen($dni) < self::VALID_LENGTH) {
18             throw new LengthException('Too short');
19         }
20 
21         throw new \DomainException('Ends with number');
22     }
23 }

Aplicamos este cambio y ejecutamos los tests para comprobar que siguen pasando.

Otra duplicación la podemos ver en las dos condicionales que controlan la longitud de la cadena. Lo cierto es que nos bastaría con lanzar la excepción si la longitud es distinta de nueve. Por ejemplo, así:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         if (\strlen($dni) !== self::VALID_LENGTH) {
15             throw new LengthException(
16                 \strlen($dni) > 9 ? 'Too long': 'Too short'
17             );
18         }
19 
20         throw new \DomainException('Ends with number');
21     }
22 }

De nuevo, con este cambio, los tests siguen pasando. Sin embargo, la expresividad ha salido un poco perjudicada, por lo que que podríamos extraer la condición y el lanzamiento de la excepción a su propio método, dejando más limpio el constructor.

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         $this->checkDniHasValidLength($dni);
15 
16         throw new \DomainException('Ends with number');
17     }
18 
19     private function checkDniHasValidLength(string $dni): void
20     {
21         if (\strlen($dni) !== self::VALID_LENGTH) {
22             throw new LengthException(
23                 \strlen($dni) > 9 ? 'Too long' : 'Too short'
24             );
25         }
26     }
27 }

Ahora lo que tenemos es una cláusula de guarda que, a la vez que oculta la complejidad, es mucho más explícita acerca de lo que ocurre.

Refactor de los tests

En este punto me gustaría plantear una cuestión interesante. El refactor también puede aplicarse a los tests. En cualquier momento podemos darnos cuenta de que tenemos tests que son redundantes o que, si bien fueron necesarios para generar el código, se han vuelto innecesarios en su estado actual.

Por eso, en la fase de refactor, podemos modificarlos siempre y cuando los mantengamos en verde.

Por ejemplo, podríamos decidir que no necesitamos chequear el mensaje de la excepción LengthException ya que para este proyecto no nos aporta nada significativo saber que la cadena sea demasiado corta o demasiado larga. Simplemente tiene el tamaño inadecuado. Si quitamos esa línea en los tests, éstos siguen pasando, que es como decir que siguen testeando lo mismo.

De hecho, no es buena práctica hacer tests basados en los mensajes de las excepciones, pero nos están siendo útiles temporalmente para poder lanzar y esperar el mismo tipo de excepción producida por causas diferentes.

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Tests\Dojo;
 5 
 6 use Dojo\Dni;
 7 use DomainException;
 8 use LengthException;
 9 use PHPUnit\Framework\TestCase;
10 
11 class DniTest extends TestCase
12 {
13     public function testShouldFailWhenDniLongerThanMaxLenght(): void
14     {
15         $this->expectException(LengthException::class);
16         $dni = new Dni('0123456789');
17     }
18 
19     public function testShouldFailWhenDniShorterThanMinLenght(): void
20     {
21         $this->expectException(LengthException::class);
22         $dni = new Dni('01234567');
23     }
24 
25     public function testShouldFailWhenDniEndsWithANumber(): void
26     {
27         $this->expectException(DomainException::class);
28         $this->expectExceptionMessage('Ends with number');
29         $dni = new Dni('012345678');
30     }
31 
32 }

Adicionalmente, ganamos la ventaja de poder simplificar un poquito más el código de producción porque no tenemos que personalizar el mensaje de error:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         $this->checkDniHasValidLength($dni);
15 
16         throw new \DomainException('Ends with number');
17     }
18 
19     private function checkDniHasValidLength(string $dni): void
20     {
21         if (\strlen($dni) !== self::VALID_LENGTH) {
22             throw new LengthException('Too long or too short');
23         }
24     }
25 }

Volviendo al rojo: hagamos un nuevo test

Después de detenernos un rato en mejorar la calidad de la implementación, con la red de seguridad que supone mantener los test existentes pasando para garantizar que no alteramos el comportamiento, llega el momento de seguir avanzando en la implementación.

Nuestro último test planteaba el problema de que el último carácter de la cadena candidata a ser un DNI no puede ser un número.

Ahora vamos a profundizar en esa condición para testear que tampoco puede ser una letra del conjunto [I, O, U, Ñ], las cuales han sido eliminadas para evitar confundirlas con otros símbolos. Una cadena de caracteres terminada en uno de éstos símbolos no puede ser un DNI y esto es lo que refleja el test:

1 public function testShouldFailWhenDniEndsWithAnInvalidLetter(): void
2 {
3     $this->expectException(DomainException::class);
4     $this->expectExceptionMessage('Ends with invalid letter');
5     $dni = new Dni('01234567I');
6 }

Test que, al ejecutarlo, falla:

1 Failed asserting that exception message 'Ends with number' contains 'Ends with inval\
2 id letter'.

Que un test falle es una gran noticia. Nos dice lo que necesitamos saber y lo que tenemos que hacer: resolver el problema que hemos pospuesto antes, o sea, comprobar que el último carácter no es un número, cosa que aquí he decidido hacer con una expresión regular:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         $this->checkDniHasValidLength($dni);
15 
16         if (preg_match('/\d$/', $dni)) {
17             throw new \DomainException('Ends with number');
18         }
19         throw new \DomainException('Ends with invalid letter');
20     }
21 
22     private function checkDniHasValidLength(string $dni): void
23     {
24         if (\strlen($dni) !== self::VALID_LENGTH) {
25             throw new LengthException('Too long or too short');
26         }
27     }
28 }

Podríamos haber escogido otra implementación con tal de hacer pasar el test, por tosca o ingenua que nos pudiese parecer. Lo importante es que consigas que funcione y, cuando sepas que funciona porque los tests pasan, es cuando intentas mejorar esa implementación que has hecho. Pero el objetivo ya está cumplido.

Poco más podemos hacer con este código, así que podemos avanzar a la siguiente condición.

La siguiente condición que voy a probar es que el DNI sólo puede estar formado por números, excepto la letra final y, en ciertos casos, la inicial. Por tanto, no puede haber caracteres que no sean números fuera de las posiciones extremas. Lo expresamos en forma de test:

1 public function testShouldFailWhenDniHasLettersInTheMiddle(): void
2 {
3     $this->expectException(DomainException::class);
4     $this->expectExceptionMessage('Has letters in the middle');
5     $dni = new Dni('012AB567R');
6 }

El test falla:

1 Failed asserting that exception message 'Ends with invalid letter' contains 'Has let\
2 ters in the middle'.

Como estamos en rojo, vamos a implementar algo que nos permita pasar el test:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         $this->checkDniHasValidLength($dni);
15 
16         if (preg_match('/\d$/', $dni)) {
17             throw new \DomainException('Ends with number');
18         }
19 
20         if (preg_match('/[UIOÑ]$/u', $dni)) {
21             throw new \DomainException('Ends with invalid letter');
22         }
23         throw new \DomainException('Has letters in the middle');
24     }
25 
26     private function checkDniHasValidLength(string $dni): void
27     {
28         if (\strlen($dni) !== self::VALID_LENGTH) {
29             throw new LengthException('Too long or too short');
30         }
31     }
32 }

De nuevo: no tenemos que preocuparnos mucho por la calidad de la implementación. Simplemente escribimos código de producción que haga pasar el test y mantenga los test anteriores pasando, de manera que seguimos teniendo el comportamiento deseado en todo momento.

En cualquier caso, con esta implementación, el test está pasando y es ahora cuando podríamos pararnos a mejorarla. Pero eso lo vamos a dejar para dentro de un rato. No tenemos que hacerlo a cada paso si no nos convence o no vemos claro cómo hacer ese refactor. Tenemos un código que no sólo funciona, sino que su funcionamiento está completamente respaldado por tests.

Ahora vamos a probar otra condición. Esta vez, trata sobre cómo debería ser el principio de la cadena. O mejor dicho: cómo no debería ser. Y la cuestión es que no debería empezar por nada que no sea un número o las letras [X, Y, Z].

Describimos eso con un test que falle:

1 public function testShouldFailWhenDniStartsWithALetterOtherThanXYZ(): void
2 {
3     $this->expectException(DomainException::class);
4     $this->expectExceptionMessage('Starts with invalid letter');
5     $dni = new Dni('A1234567R');
6 }

El código de producción que hace pasar este test es el siguiente:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         $this->checkDniHasValidLength($dni);
15 
16         if (preg_match('/\d$/', $dni)) {
17             throw new \DomainException('Ends with number');
18         }
19 
20         if (preg_match('/[UIOÑ]$/u', $dni)) {
21             throw new \DomainException('Ends with invalid letter');
22         }
23 
24         if (! preg_match('/\d{7,7}.$/', $dni)) {
25             throw new \DomainException('Has letters in the middle');
26         }
27         throw new \DomainException('Starts with invalid letter');
28     }
29 
30     private function checkDniHasValidLength(string $dni): void
31     {
32         if (\strlen($dni) !== self::VALID_LENGTH) {
33             throw new LengthException('Too long or too short');
34         }
35     }
36 }

De nuevo, posponemos la solución de ese problema a la siguiente iteración. El caso es que, con el último test, hemos definido ya todas las condiciones que debería cumplir una cadena de caracteres para poder ser un DNI aunque, recordemos, en realidad todavía no hemos implementado todo ese comportamiento ya que necesitamos un nuevo test que nos obligue a ello.

Ahora mos toca entrar en el terreno del algoritmo del validación en sí.

Este algoritmo se basa en obtener el resto de la división de la parte numérica del DNI entre 23. Con este resto buscamos la letra de control en la tabla de correspondencias y la comparamos con la que finaliza la cadena. Si coinciden, el DNI es válido. Si no coinciden, lanzaremos una excepción.

A partir de ahora, la validez de la cadena candidata como DNI vendrá determinada por el resultado de aplicar el algoritmo. Además, a partir de ahora vamos a seguir un modelo de validación pesimista en el que, por defecto, asumiremos que la cadena de caracteres es inválida salvo que se demuestre lo contrario al aplicar el algoritmo.

Por tanto en nuestro siguiente test vamos a probar que se lanza excepción cuando la cadena candidata no es válida.

Encontrar ejemplos para generar tests es muy fácil, ya que nos basta con utilizar las cadenas desde 00000000 a 00000022. En la siguiente tabla de correspondencia tenemos los ejemplos válidos:

Para generar un caso no válido, nos basta con tomar cualquiera de las secuencias numéricas y asociarla con cualquier letra excepto la propia. Por ejemplo: 00000000S (o 00000000 con cualquier letra que no sea la T).

Y el test sería más o menos así:

1 public function testShouldFailWhenInvalidDni(): void
2 {
3     $this->expectException(InvalidArgumentException::class);
4     $dni = new Dni('00000000S');
5 }

El cual falla porque no se lanza la excepción esperada:

1 Failed asserting that exception of type "DomainException" matches expected exception\
2  "InvalidArgumentException". Message was: "Starts with invalid letter" at
3 /Users/frankie/Sites/dojo/src/Dni.php:27
4 /Users/frankie/Sites/dojo/tests/Dojo/DniTest.php:57.

De nuevo, para pasar el test debemos resolver primero el problema que dejamos pendiente en el anterior:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Dojo;
 5 
 6 use LengthException;
 7 
 8 class Dni
 9 {
10     private const VALID_LENGTH = 9;
11 
12     public function __construct(string $dni)
13     {
14         $this->checkDniHasValidLength($dni);
15 
16         if (preg_match('/\d$/', $dni)) {
17             throw new \DomainException('Ends with number');
18         }
19 
20         if (preg_match('/[UIOÑ]$/u', $dni)) {
21             throw new \DomainException('Ends with invalid letter');
22         }
23 
24         if (! preg_match('/\d{7,7}.$/', $dni)) {
25             throw new \DomainException('Has letters in the middle');
26         }
27 
28         if (! preg_match('/^[XYZ0-9]/', $dni)) {
29             throw new \DomainException('Starts with invalid letter');
30         }
31         throw new \InvalidArgumentException('Invalid dni');
32     }
33 
34     private function checkDniHasValidLength(string $dni): void
35     {
36         if (\strlen($dni) !== self::VALID_LENGTH) {
37             throw new LengthException('Too long or too short');
38         }
39     }
40 }

Refactor

El caso es que si ahora observamos el código de producción que tenemos es fácil pensar que podría hacerse más conciso. Tenemos cuatro estructuras condicionales que comprueban el match de una expresión regular y, aunque son diferentes patrones, se puede ver que estamos ante una forma de duplicación innecesaria.

Pero para hacerlo tengo que modificar un poco los tests, ya que no quiero depender de los mensajes de las excepciones¹. En principio, eliminar la comprobación de los mensajes no afectará al resultado del test.

El TestCase ahora mismo es así:

 1 <?php
 2 declare(strict_types=1);
 3 
 4 namespace Tests\Dojo;
 5 
 6 use Dojo\Dni;
 7 use DomainException;
 8 use InvalidArgumentException;
 9 use LengthException;
10 use PHPUnit\Framework\TestCase;
11 
12 class DniTest extends TestCase
13 {
14     public function testShouldFailWhenDniLongerThanMaxLenght(): void
15     {
16         $this->expectException(LengthException::class);
17         $dni = new Dni('0123456789');
18     }
19 
20     public function testShouldFailWhenDniShorterThanMinLenght(): void
21     {
22         $this->expectException(LengthException::class);
23         $dni = new Dni('01234567');
24     }
25 
26     public function testShouldFailWhenDniEndsWithANumber(): void
27     {
28         $this->expectException(DomainException::class);
29         $dni = new Dni('012345678');
30     }
31 
32     public function testShouldFailWhenDniEndsWithAnInvalidLetter(): void
33     {
34         $this->expectException(DomainException::class);
35         $dni = new Dni('01234567I');
36     }
37 
38     public function testShouldFailWhenDniHasLettersInTheMiddle(): void
39     {
40         $this->expectException(DomainException::class);
41         $dni = new Dni('012AB567R');
42     }
43 
44     public function testShouldFailWhenDniStartsWithALetterOtherThanXYZ(): void
45     {
46         $this->expectException(DomainException::class);
47         $dni = new Dni('A1234567R');
48     }
49 
50     public function testShouldFailWhenInvalidDni(): void
51     {
52         $this->expectException(InvalidArgumentException::class);
53         $dni = new Dni('00000000S');
54     }
55 }