Apéndices

\nPHPUnit Instrucciones básicas para instalar y configurar phpunit en un proyecto.
\nPHPSpec Instrucciones básicas para instalar y configurar phpspec en un proyecto, junto con una pequeña guía para entender sus similitudes y diferencias con phpunit.

",{"_516":517,"_42":43,"_46":47,"_44":45,"_64":65,"_518":519,"_647":514},"previewContent","

Tabla de contenidos

\n Introducción: Del ojímetro al tdd\n
- \n Entonces descubres los tests\n
- \n Control de calidad\n
- \n Tests funcionales\n
- \n Anatomía de un test\n
- \n Manejo de las dependencias\n
- \n Cuándo toca hacer tests\n
- \n Test Driven Development\n
- \n Qué incluir en los tests y qué no\n
- \n Y esto es casi todo\n
\n
\n Testing desde cero\n
- \n Qué es software testing\n
- \n A mano o a máquina\n
- \n Qué sometemos a test\n
- \n Qué es hacer un test\n
- \n Estructura básica de un test\n
- \n La elección de los casos para testear\n
- \n Frameworks para testing\n
- \n Cuándo testear\n
\n
\n Testing en contexto\n
- \n Taxonomía de tests\n
- \n La pirámide de tests funcionales\n
- \n Utilidad de la pirámide de tests\n
- \n Smells en la pirámide de los tests funcionales\n
\n
\n Psicología del testing\n
- \n ¿Por qué nos cuesta el testing?\n
- \n El concepto de test y la necesidad de testear\n
- \n Sentimos apego por nuestro código\n
- \n La dificultad técnica del testing\n
- \n La presión para no testear\n
- \n Testear no es igual a confirmar que funciona\n
- \n Responsabilidad y testeo\n
\n
\n Primer test\n
\n TDD de un validador de NIF\n
- \n Testeando lo que no es válido\n
- \n Toca refactor\n
- \n Nuevos casos no válidos\n
- \n Dos por el precio de uno\n
- \n Concluyendo\n
\n
\n Desarrollar un algoritmo paso a paso con TDD: Luhn Test kata\n
- \n Sobre la Luhn Test kata\n
- \n Empecemos con un test\n
- \n Empezando con el código de producción\n
- \n Buscando un nuevo ejemplo\n
- \n Los tests deben forzar implementaciones\n
- \n Buscando un algoritmo más general\n
- \n Añadiendo prestaciones\n
\n
\n Clean testing\n
- \n Naming de los test\n
- \n Eliminar los números mágicos\n
- \n Extrae métodos, también en tests\n
- \n Esperar excepciones\n
- \n Métodos assert\n
\n
\n Test doubles (1)\n
- \n El concepto de test double\n
- \n Por qué y para qué de los tests doubles\n
- \n Test doubles y dónde encontrarlos\n
- \n Alternativas para generar test doubles\n
- \n Terminando\n
\n
\n Test doubles (2) Principios de diseño\n
- \n Principios de diseño y doubles\n
- \n Un ejemplo\n
- \n En resumen\n
\n
\n Resolver problemas con baby-steps\n
- \n Un problema sencillo, pero con intríngulis\n
- \n Un problema de TDD\n
- \n El enfoque de tests antes que el código pero que no es TDD\n
- \n El enfoque TDD\n
- \n Conclusiones\n
\n
\n Usar el code coverage para mejorar los tests\n
- \n Code coverage y refactoring\n
- \n Para finalizar\n
\n
\n Testeando lo impredecible\n
- \n Generando contraseñas para humanos\n
- \n Determinismo y predictibilidad\n
- \n A ver qué sale\n
- \n Generando un password legible\n
- \n Testeando el azar\n
- \n Probamos nuestro generador de constraseñas\n
- \n Queremos contraseñas más difíciles\n
- \n Decorar es extender por composición\n
- \n Veamos cómo usarlo\n
- \n Cosas por hacer\n
- \n Algunas referencias\n
\n
\n TDD en PHP. Un ejemplo con colecciones (1)\n
- \n ¿Qué tendría que tener una clase Collection?\n
- \n Escribiendo el primer mínimo test que falle\n
- \n Pongamos un poco de comportamiento aquí\n
- \n Controlando qué ponemos en la colección\n
- \n Refactorizar el test\n
- \n Antes de terminar, hagamos unos arreglos\n
- \n Y un extra\n
- \n Fin del primer acto\n
\n
\n TDD en PHP. Un ejemplo con colecciones (2)\n
- \n Testing dirigido por Checklist\n
- \n Filosofía de las colecciones\n
- \n Implementar el método each\n
- \n Recapitulando each\n
\n
\n TDD en PHP. Un ejemplo con colecciones (3)\n
- \n Pipeline en el método each\n
- \n Una digresión: mutable, modificable o todo lo contrario\n
- \n Antes de implementar el método map\n
- \n Implementando map\n
- \n Para finalizar (por ahora)\n
\n
\n TDD en PHP. Un ejemplo con colecciones (4)\n
- \n Estos artículos van de TDD más que de Collections\n
- \n Filtrando una colección\n
- \n Ahorrando algunos tests con return type y type hinting\n
- \n ¿Algo que refactorizar?\n
- \n Devolver un objeto\n
- \n Fin del capítulo\n
\n
\n TDD en PHP. Un ejemplo con colecciones (5)\n
- \n Reduciendo colecciones\n
- \n Métodos útiles para nuestras colecciones\n
- \n Devolviendo el contenido de la colección\n
- \n Métodos de utilidad\n
- \n Refactor final\n
\n
\n Apéndices\n
\n Apéndice 1: PhpUnit\n
- \n Instalación\n
- \n Configuración básica\n
\n
\n Apéndice 2: PhpSpec\n
- \n Instalación\n
- \n Configuración inicial\n
- \n Specification by example\n
- \n Primera especificación\n
\n
\n Notas\n

Introducción: Del ojímetro al tdd

\n\n

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

\n\n

Cuando empiezas a programar en PHP (y 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í.

\n\n

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

\n\n

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.

\n\n

Y el ciclo se repite.

\n\n

¿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.

\n\n

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.

\n\n

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

\n\n

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.

\n\n

Entonces descubres los tests

\n\n

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

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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

\n\n

Control de calidad

\n\n

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

\n\n

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.

\n\n

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.

\n\n

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.

\n\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.

\n\n

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.

\n\n

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

\n\n

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

\n\n

Lo que vemos al recargar una página es el resultado de un conjunto de operaciones, una de las cuales 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, por efecto del algoritmo que hemos escrito, sino que podría haber efectos colaterales de diversos componentes del programa.

\n\n

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

\n\n

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.

\n\n

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.

\n\n

Tests funcionales

\n\n

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:

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Hablaremos de ello dentro de un rato.

\n\n

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.

\n\n

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.

\n\n

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.

\n\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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Anatomía de un test

\n\n

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:

\n\n

Dado…

\n\n

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

\n\n

Cuando…

\n\n

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

\n\n

Entonces…

\n\n

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…

\n\n

Manejo de las dependencias

\n\n

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.

\n\n

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.

\n\n

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

\n\n

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

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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

\n\n

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.

\n\n

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:

\n\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.

\n\n

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.

\n\n

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

\n\n

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.

\n\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”.

\n\n

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á.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

El ejemplo clásico, son las implementaciones en memoria de repositorios, bases de datos, sistemas de archivos, etc.

\n\n

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

\n\n

Cuándo toca hacer tests

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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

\n\n

Test Driven Development

\n\n

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.

\n\n

Me explico:

\n\n

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.

\n\n

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:

\n\n

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

\n\n

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.

\n\n

Ahora ejecutas el test.

\n\n

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

\n\n

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

\n\n

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

\n\n

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 de “escritura” nos vale.

\n\n

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…

\n\n

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:

\n\n

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

\n\n

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.

\n\n

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

\n\n

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

\n\n

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.

\n\n

\n
– ¡Me estás tomando el pelo!
\n

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Qué incluir en los tests y qué no

\n\n

Depende.

\n\n

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

\n\n

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

\n\n

Cosas más o menos claras

\n\n

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

\n\n

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.

\n\n

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

\n\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.

\n\n

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

\n\n

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.

\n\n

Code Coverage

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Y esto es casi todo

\n\n

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.

\n\n

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 http://franiglesias.github.io o en twitter #talkingbit1.

\n\n

Gracias por seguir leyendo.

\n\n\n

Testing desde cero

\n\n

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.

\n\n

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.

\n\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.

\n\n

Qué es software testing

\n\n

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.

\n\n

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

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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

\n\n

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.

\n\n

Reckless, Claire: So, What Is Software Testing?

\n\n

A mano o a máquina

\n\n

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

\n\n

Podemos hacerlo de forma manual o automatizarlo.

\n\n

Testing manual

\n\n

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

\n\n

Sus limitaciones deberían ser evidentes:

\n\n

Examinamos un número limitado de posibles caso, 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.

\n\n

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.

\n\n

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.

\n\n

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

\n\n

Testing automático

\n\n

El testeo manual tiene muchas limitaciones:

\n\n

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.

\n\n

La respuesta es automatizarlo.

\n\n

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

\n\n

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.

\n\n

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

\n\n

Qué sometemos a test

\n\n

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

\n\n

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.

\n\n

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:

\n\n

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.

\n\n

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

\n\n

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.

\n\n

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.

\n\n

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 tiene especial valor cuando estamos desarrollando.

\n\n

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

\n\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.

\n\n

Qué es hacer un test

\n\n

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:

\n\n

\nQueries: son piezas de software que devuelven una respuesta al ser ejecutadas. Por lo tanto, podemos tomar esa respuesta y compararla con la respuesta esperada.
\nCommands: 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.

\n\n

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.

\n\n

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.

\n\n

Estructura básica de un test

\n\n

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.

\n\n

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

\n\n

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

\n\n

Fundamentalmente, los tests tienen tres partes principales:

\n\n

\nGiven 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.
\nWhen o Act: La segunda es la ejecución de la unidad de software y la obtención del resultado.
\nThen 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.

\n\n

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.

\n\n

Maksimovic, Zoran: The anatomy of a Unit Test

\n\n

La elección de los casos para testear

\n\n

¿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.

\n\n

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

\n\n

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:

\n\n

\nTests 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.
\nTests 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.

\n\n

Tests de caja negra

\n\n

Valores únicos

\n\n

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

\n\n

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.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Código	Valor
COOL	10
SUPER	30
GREAT	20

\n\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.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Código	Valor
COOL	10
SUPER	30
GREAT	20
BUUUU	0
	0

\n\n

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

\n\n

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

\n\n

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

\n\n

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.

\n\n

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

\n\n

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%.

\n\n

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:

\n\n

1 0    10                  50                      100\n2 |----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|\n3   0 ][         10%       ][          15%         ][           20%   \n

\n\n\n\n

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:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Intervalo	Valor a probar	Resultado
0-9	5	0%
10-49	20	10%
50-99	75	15%
100+	120	20%

\n\n

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

\n\n

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

\n\n

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:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Intervalo	Valor a probar	Resultado
0-9	9	0%
10-49	10	10%
10-49	49	10%
50-99	50	15%
50-99	99	15%
100+	120	20%

\n\n

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”.

\n\n

Decision table (tabla de decisión)

\n\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.

\n\n

Retomando un viejo ejemplo de este mismo blog, 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.

\n\n

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

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Casos ->	1	2	3	4	5	6	7	8	9	10	11	12
Condiciones
Modelo	M	M	M	M	M	M	W	W	W	W	W	W
Talla	S	S	M	M	L	L	S	S	M	M	L	L
Tamaño	B	S	B	S	B	S	B	S	B	S	B	S
Acciones(precios)	25	20	35	30	45	40	25	20	35	30	45	40

\n\n

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

\n\n

Tests de caja blanca

\n\n

Basic path

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Code coverage o Line Coverage

\n\n

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.

\n\n

Branch coverage

\n\n

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.

\n\n

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.

\n\n

Frameworks para testing

\n\n

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.

\n\n

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

\n\n

function shouldCalculateFee()\n{\n // Given / Arrange \n var consumption = 1000;\n var power = 1200;\n var optimalPower = 1150;

\n\n

1 // When / Act\n2 var fee = calculateFee(consumption, power, optimalPower);\n3 \n4 // Then / Assert\n5 if (45 == fee) {\n6     return 'ok'\n7 } \n8 \n9 throw Exception('CalculateFee failed')\n

\n\n\n\n

}

\n\n

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

\n\n

 1 function shouldCalculateFee()\n 2 {\n 3     // Given / Arrange \n 4     var consumption = 1000;\n 5     var power = 1200;\n 6     var optimalPower = 1150;\n 7     \n 8     // When / Act\n 9     $fee = calculateFee(consumption, power, optimalPower);\n10     \n11     // Then / Assert\n12     assertEquals(45, fee);\n13 }\n

\n\n\n\n

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

\n\n

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.

\n\n

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.

\n\n

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

\n\n

\nxUnit: es el tipo más genérico. Los tests se estructura en TestCases y utiliza aserciones para verificar los resultados (JUnit, PHPUNit, etc).
\nxSpec: 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).
\nxBehave: son frameworks para Behavior Driven Development, se orientan a la realización de tests de aceptación (JBehave, Cucumber, Behat).

\n\n

Cuándo testear

\n\n

Después de escribir el código

\n\n

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 QA. La idea es probar que el código cumple las especificaciones y detectar posibles fallos o casos no cubiertos.

\n\n

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.

\n\n

Esto presenta dos problemas principales:

\n\n

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.

\n\n

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 puede ocurrir cuando en el desarrollo no se ha realizado una buena gestión de la dependencias y se da alto acoplamiento entre clases.

\n\n

Antes de escribir el código

\n\n

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.

\n\n

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.

\n\n

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

\n\n

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.

\n\n

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

\n\n

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?

\n\n

Para describir un bug

\n\n

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, fallando, ponga de manifiesto el problema observado.

\n\n

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.

\n\n

Para refactorizar un código

\n\n

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.

\n\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.

\n\n\n

Testing en contexto

\n\n

Taxonomía de tests

\n\n

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

\n\n

Tests funcionales
Tests no funcionales

\n\n

Tests funcionales

\n\n

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.

\n\n

Esto se puede probar a varios niveles, a saber:

\n\n

\nTests unitarios: probando las unidades básicas en que está organizado el software funcionando de manera aislada.
\nTests de integración: probando conjuntos de unidades básicas que están relacionadas entre sí, para comprobar que sus relaciones funcionan correctamente.
\nTests 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)

\n\n

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

\n\n

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

\n\n

\nTests 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.
\nTests 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.

\n\n

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.

\n\n

Tests no funcionales

\n\n

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:

\n\n

\nVelocidad: Nos dice si el software devuelve resultados en el tiempo deseado.
\nCarga: 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.
\nRecuperación: Nos dice si un sistema es capaz de recuperarse correctamente en caso de fallo.
\nTolerancia a fallos: Nos dice si el sistema reacciona correctamente si se producen fallos en otros sistemas de los que depende.

\n\n

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.

\n\n

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.

\n\n

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

\n\n

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).

\n\n

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:

\n\n

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.

\n\n

La pirámide de tests funcionales

\n\n

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

\n\n

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

\n\n

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

\n\n

O dicho de otra forma:

\n\n

Dada una feature de nuestro software tendríamos:

\n\n

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.

\n\n

Pero, ¿por qué?

\n\n

Muchos tests unitarios

\n\n

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

\n\n

\nFá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.
\nRá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.
\nReplicables: podemos repetir los tests cuantas veces sea necesario, obteniendo los mismos resultados si el comportamiento de la unidad de software no ha sido alterado.

\n\n

Estas condiciones nos permiten hacer cosas como:

\n\n

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.

\n\n

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.

\n\n

¿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.

\n\n

En los tests unitarios, los comportamientos de otras unidades de software que pudiesen intervenir se simulan mediante tests 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.

\n\n

Un número medio de tests de integración

\n\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.

\n\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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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

\n\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.

\n\n

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

\n\n

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

\n\n

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.

\n\n

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

\n\n

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

\n\n

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 mismas unidades de software implicadas.

\n\n

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.

\n\n

Utilidad de la pirámide de tests

\n\n

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.

\n\n

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

\n\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.

\n\n

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:

\n\n

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.

\n\n

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

\n\n

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.

\n\n

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:

\n\n

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 podremos 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.

\n\n

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

\n\n

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

\n\n

Smells en la pirámide de los tests funcionales

\n\n

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.

\n\n

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.

\n\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.

\n\n

Pirámide invertida

\n\n

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

\n\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.

\n\n

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

\n\n

Pirámide aplastada

\n\n

La pirámide aplastada indicaría que hay demasiado 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.

\n\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.

\n\n

Forma de diábolo

\n\n

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.

\n\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.

\n\n

Forma de rombo

\n\n

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.

\n\n

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

\n\n

Forma de cuadrado

\n\n

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.

\n\n\n

Psicología del testing

\n\n

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

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

¿Por qué nos cuesta el testing?

\n\n

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.

\n\n

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

\n\n

1 $result = // exec some software unit\n2 \n3 if ($expected === $result) {\n4 \techo 'OK: the software unit works as expected';\n5 } else {\n6 \techo 'Something is wrong!'\n7 }\n

\n\n\n\n

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.

\n\n

Pero no vamos a tratar aquí de esas cuestiones.

\n\n

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.

\n\n

El concepto de test y la necesidad de testear

\n\n

¿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.

\n\n

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?

\n\n

He aquí algunas razones:

\n\n

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.
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.
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.
Es automatizable: podemos programar la ejecución del test en cualquier momento que necesitemos, junto con todos los demás test que tengamos.

\n\n

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.

\n\n

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.

\n\n

Sentimos apego por nuestro código

\n\n

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.

\n\n

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 pueda suponer, de lo que trataremos más adelante, sino por la disonancia que nos genera ser críticos con nuestra propia obra.

\n\n

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

\n\n

\nTarea 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”.
\nLa 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).

\n\n

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.

\n\n

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

\n\n

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.

\n\n

La dificultad técnica del testing

\n\n

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.

\n\n

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

\n\n

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.

\n\n

La presión para no testear

\n\n

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.

\n\n

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

\n\n

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

\n\n

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?

\n\n

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.

\n\n

Testear no es igual a confirmar que funciona

\n\n

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.

\n\n

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 funciona nos aporte información y podamos aceptarla provisionalmente.

\n\n

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.

\n\n

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.

\n\n

Responsabilidad y testeo

\n\n

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?

\n\n

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?

\n\n

¿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:

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n\n

Primer test

\n\n\n

TDD de un validador de NIF

\n\n

Hay validadores de NIF a espuertas, pero escribir uno con TDD resulta ser un interesante ejercicio con el que desarrollar algunas estrategias de test.

\n\n

Un DNI 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.

\n\n

El algoritmo para validar un NIF 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.

\n\n

La tabla en cuestión es esta:

Resto	Letra
0	T
1	R
2	W
3	A
4	G
5	M
6	Y
7	F
8	P
9	D
10	X
11	B
12	N
13	J
14	Z
15	S
16	Q
17	V
18	H
19	L
20	C
21	K
22	E

\n\n

Como siempre, comenzamos con un test.

\n\n

Voy a empezar con un test que falle esperando un NIF válido. Podríamos usar uno conocido que sepamos que lo es, o calcular uno sencillo que sepamos que tendría que ser válido. Es el caso de 00000000T. En realidad si multiplicamos 23 por los números desde el 0 al 22 obtendremos NIFs válidos para cada letra, pero ya nos ocuparemos luego de eso.

\n\n

1 class ValidateNifTest extends TestCase\n2 {\n3     public function testShouldValidateAValidNif()\n4     {\n5         $nif = '00000000T';\n6         $validateNif = new ValidateNif();\n7         $this->assertTrue($validateNif->do($nif));\n8     }\n9 }\n

\n\n\n\n

Para pasar este test hay que hacer tres cosas:

\n\n

Crear la Clase ValidateNif
Añadirle el método do
Hacer que devuelva true

\n\n

1 class ValidateNif\n2 {\n3 \n4     public function do(string $nif): bool\n5     {\n6         return true;\n7     }\n8 }\n

\n\n\n\n

Ya tenemos el primer test pasando.

\n\n

Testeando lo que no es válido

\n\n

Testear validadores o cualquier método que devuelva resultados booleanos tiene un poco de truco, porque sólo tenemos dos respuestas posibles. Por eso, normalmente querremos empezar por un caso para generar nuestra primera implementación mínima e inflexible y, después, empezar a explorar casos que la contradigan.

\n\n

La estrategia que vamos a seguir en esta ocasión es centrarnos primero en los casos de NIFs que no son válidos. Ahora necesitamos un nuevo test que falle esperando que el siguiente NIF no sea válido.

\n\n

Lo cierto es que hay varios ejemplos de NIF que no son válidos porque no cumplen los requisitos básicos de número de caracteres, así que podemos empezar por conseguir que nuestro ValidateNif los rechace.

\n\n

En lugar de testear que el validador sólo admite cadenas de nueve caracteres (ocho números y una letra) lo que vamos a hacer es testear que los strings de más de 9 caracteres nunca serán válidos.

\n\n

Aquí tenemos el test que falla:

\n\n

1     public function testTooLongStringsAreNotValid()\n2     {\n3         $nif = '000000000T';\n4         $validateNif = new ValidateNif();\n5         $this->assertFalse($validateNif->do($nif));\n6     }\n

\n\n\n\n

Y aquí lo hemos hecho pasar:

\n\n

1     public function do(string $nif): bool\n2     {\n3         if (strlen($nif) > 9) {\n4             return false;\n5         }\n6         return true;\n7     }\n

\n\n\n\n

La clave está en lo siguiente: nuestra primera implementación inflexible siempre devuelve true, por lo que si testeamos ejemplos no válidos de NIF nuestros tests siempre empezarán fallando, que es lo que nos aporta información.

\n\n

Al añadir código para hacer pasar estos tests nos estamos obligando a tratar con esos casos que no deberían entrar al algoritmo de validación. Como, por ejemplo, los que son demasiado cortos.

\n\n

Una nota sobre este tipo de casos: puede que ya tengamos validaciones por front-end de datos introducidos por usuarios, pero nunca está de más. A lo mejor otra fuente de entrada de datos es un archivo CSV o la respuesta de un API en las que puede que no contemos con esa primera barrera de defensa.

\n\n

En fin, volviendo al tema, aquí tenemos un test para probar que nuestra clase sabe lidiar con NIFs demasiado cortos.

\n\n

1     public function testTooShortStringsAreNotValid()\n2     {\n3         $nif = '0000000T';\n4         $validateNif = new ValidateNif();\n5         $this->assertFalse($validateNif->do($nif));\n6     }\n

\n\n\n\n

Test que podemos hacer pasar con el siguiente código:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     public function do(string $nif) : bool\n 5     {\n 6         if (strlen($nif) > 9) {\n 7             return false;\n 8         }\n 9         if (strlen($nif) < 9) {\n10             return false;\n11         }\n12 \n13         return true;\n14     }\n15 }\n

\n\n\n\n

Toca refactor

\n\n

La duplicación ha venido y todos hemos visto como ha sido. En el código de producción ya podemos visualizar una repetición de código y es buen momento para empezar a refactorizar.

\n\n

Se trata de mantener los tests en verde y cambiar el código para eliminar esa duplicación y otros posibles smells. De hecho, también tenemos un número mágico, el 9 y deberíamos hacer algo al respecto.

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     const NIF_LENGTH = 9;\n 5 \n 6     public function do(string $nif) : bool\n 7     {\n 8         if (strlen($nif) !== self::NIF_LENGTH) {\n 9             return false;\n10         }\n11 \n12         return true;\n13     }\n14 }\n

\n\n\n\n

Como los tests se mantienen pasando es que lo estamos haciendo bien. También es buen momento de reducir la duplicación en los propios tests:

\n\n

 1 class ValidateNifTest extends TestCase\n 2 {\n 3     private $validateNif;\n 4 \n 5     public function setUp()\n 6     {\n 7         $this->validateNif = new ValidateNif();\n 8     }\n 9     public function testShouldValidateAValidNif()\n10     {\n11         $nif = '00000000T';\n12         $this->assertTrue($this->validateNif->do($nif));\n13     }\n14 \n15     public function testTooLongStringsAreNotValid()\n16     {\n17         $nif = '000000000T';\n18         $this->assertFalse($this->validateNif->do($nif));\n19     }\n20 \n21     public function testTooShortStringsAreNotValid()\n22     {\n23         $nif = '0000000T';\n24         $this->assertFalse($this->validateNif->do($nif));\n25     }\n26 }\n

\n\n\n\n

Nuevos casos no válidos

\n\n

Tampoco serán válidos los casos en los que no haya ninguna letra o más de dos. El resto de caracteres serán números.

\n\n

De hecho podemos ser más precisos, si el último carácter de la cadena no es una letra, el NIF no es válido.

\n\n

1     public function testLastCharIsNotAlfabeticalIsInvalid()\n2     {\n3         $nif = '000000000';\n4         $this->assertFalse($this->validateNif->do($nif));\n5     }\n

\n\n\n\n

He aquí un código que hace pasar el test:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     const NIF_LENGTH = 9;\n 5 \n 6     public function do(string $nif) : bool\n 7     {\n 8         if (strlen($nif) !== self::NIF_LENGTH) {\n 9             return false;\n10         }\n11 \n12         if (!preg_match('/[a-z]$/i', $nif)) {\n13             return false;\n14         }\n15         \n16         return true;\n17     }\n18 }\n

\n\n\n\n

Lo cierto es que este control es un poco permisivo ya que deja pasar cualquier letra y hay algunas que se han excluido como dígito de control (I, Ñ, O, U) para evitar confusiones.

\n\n

Podemos tratar eso ahora o dejarlo para más adelante, y eso es lo que vamos a hacer.

\n\n

Dos por el precio de uno

\n\n

El algoritmo también vale para el NIE (Número de Identificación para Extranjeros), que se diferencia del NIF en que comienza por una de las letras X, Y, Z.

\n\n

Así que tenemos que hacer un test que compruebe que rechazamos correctamente los documentos que no comiencen por un número ni por una de las tres letras.

\n\n

Test al canto:

\n\n

1     public function testFirstCharIsNotAllowedAlfaIsInvalid()\n2     {\n3         $nif = 'A0000000T';\n4         $this->assertFalse($this->validateNif->do($nif));\n5     }\n

\n\n\n\n

Y he aquí el código que lo pasa:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     const NIF_LENGTH = 9;\n 5 \n 6     public function do(string $nif) : bool\n 7     {\n 8         if (strlen($nif) !== self::NIF_LENGTH) {\n 9             return false;\n10         }\n11 \n12         if (!preg_match('/[a-z]$/i', $nif)) {\n13             return false;\n14         }\n15 \n16         if (!preg_match('/^[\\dxyz]/i', $nif)) {\n17             return false;\n18         }\n19 \n20         return true;\n21     }\n22 }\n

\n\n\n\n

Llegados a este punto podemos observar que tenemos algo de duplicación en el código de producción, aunque no va a ser tan fácil de resolver como la anterior y no vemos una manera evidente de hacerlo (sin adelantarnos demasiado).

\n\n

El caso es que estamos comprobando que los extremos de la cadena no sean inválidos y también nos interesaría asegurarnos de que el resto de la misma tampoco puede ser inválido.

\n\n

Toca introducir un nuevo test que nos permita probar eso:

\n\n

1     public function testNonNumericCharsINTheMiddeleIsInvalid()\n2     {\n3         $nif = '00abc000T';\n4         $this->assertFalse($this->validateNif->do($nif));\n5     }\n

\n\n\n\n

Con el test fallando, procedemos a implementar una solución:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     const NIF_LENGTH = 9;\n 5 \n 6     public function do(string $nif) : bool\n 7     {\n 8         if (strlen($nif) !== self::NIF_LENGTH) {\n 9             return false;\n10         }\n11 \n12         if (!preg_match('/[a-z]$/i', $nif)) {\n13             return false;\n14         }\n15 \n16         if (!preg_match('/^[\\dxyz]/i', $nif)) {\n17             return false;\n18         }\n19 \n20         if (!preg_match('/^[\\dxyz]\\d{7,7}/i', $nif)) {\n21             return false;\n22         }\n23 \n24         return true;\n25     }\n26 }\n

\n\n\n\n

Con este código, el test pasa y podemos plantearnos refactorizar para eliminar la duplicación que ahora hemos acentuado más.

\n\n

Las tres condicionales que usan una expresión regular para controlar sus casos correspondientes se pueden fusionar en una.

\n\n

Y al hacer el refactor mantenemos los test pasando:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     const NIF_LENGTH = 9;\n 5 \n 6     public function do(string $nif) : bool\n 7     {\n 8         if (strlen($nif) !== self::NIF_LENGTH) {\n 9             return false;\n10         }\n11         \n12         if (!preg_match('/^[\\dxyz]\\d{7,7}[a-z]$/i', $nif)) {\n13             return false;\n14         }\n15 \n16         return true;\n17     }\n18 }\n

\n\n\n\n

Esto ha estado bien, pero puede estar aún mejor. Por si no te habías dado cuenta ya, nuestra regexp duplica la lógica que controla la longitud de la cadena. Como tenemos tests, no tenemos miedo a probar este cambio:

\n\n

 1 class ValidateNif\n 2 {\n 3     public function do(string $nif) : bool\n 4     {\n 5         if (!preg_match('/^[\\dxyz]\\d{7,7}[a-z]$/i', $nif)) {\n 6             return false;\n 7         }\n 8 \n 9         return true;\n10     }\n11 }\n

\n\n\n\n

Y para ser aún más explícitos:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     private const NIF_FORMAT = '/^[\\dxyz]\\d{7,7}[a-z]$/i';\n 5 \n 6     public function do(string $nif) : bool\n 7     {\n 8         if (!preg_match(self::NIF_FORMAT, $nif)) {\n 9             return false;\n10         }\n11 \n12         return true;\n13     }\n14 }\n

\n\n\n\n

Con lo que tenemos ahora podemos excluir casi todos los casos de NIF mal formados. Ahora nos tocaría implementar el algoritmo en sí.

\n\n

Nuestro primer caso de un NIF válido está probado con el primer test, por lo que tendríamos que seguir probando con NIF inválidos pero cuyo formato sea correcto, de modo que nos fuerce a escribir código para el algoritmo.

\n\n

Por ejemplo, el NIF ‘00000001T’ fallará, pues debería tener la letra R en lugar de la T.

\n\n

1     public function testBadControlDigitShoulfBeInvalid()\n2     {\n3         $nif = '00000001T';\n4         $this->assertFalse($this->validateNif->do($nif));\n5     }\n

\n\n\n\n

La razón de que sea inválido es que al calcular el resto de dividir la parte numérica por 23, dará 1.

\n\n

El caso es que como ya conocemos el algoritmo, comenzamos a implementarlo, aunque de esta manera, de momento:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     private const NIF_FORMAT = '/^[\\dxyz]\\d{7,7}[a-z]$/i';\n 5 \n 6     public function do(string $nif) : bool\n 7     {\n 8         if (!preg_match(self::NIF_FORMAT, $nif)) {\n 9             return false;\n10         }\n11 \n12         $number = (int) substr($nif, 0, 8);\n13         $modulus = $number % 23;\n14         $control = strtolower(substr($nif, -1));\n15 \n16         if ($modulus === 0 && $control === 't') {\n17             return true;\n18         }\n19 \n20         return false;\n21     }\n22 }\n

\n\n\n\n

De momento, es una implementación un poco farragosa, pero tenemos dos cosas:

\n\n

Hemos introducido el algoritmo y la implementación ya no es inflexible del todo.
Ahora, el algoritmo fallará para NIF que son válidos, por lo que podemos ir probando casos válidos que nos obliguen a implementar la tabla de referencia.

\n\n

Así que podemos introducir un dataProvider con una lista de casos válidos, como éstos:

Casos
00000000T
00000001R
00000002W
00000003A
00000004G
00000005M
00000006Y
00000007F
00000008P
00000009D
00000010X
00000011B
00000012N
00000013J
00000014Z
00000015S
00000016Q
00000017V
00000018H
00000019L
00000020C
00000021K
00000022E

\n\n

Y he aquí el test:

\n\n

 1     /** @dataProvider validNIFS */\n 2     public function testShouldBeValidNifs($nif)\n 3     {\n 4         $this->assertTrue($this->validateNif->do($nif));\n 5     }\n 6 \n 7     public function validNIFS()\n 8     {\n 9         return [\n10             'T' => ['00000000T'],\n11             'R' => ['00000001R'],\n12             'W' => ['00000002W'],\n13             'A' => ['00000003A'],\n14             'G' => ['00000004G'],\n15             'M' => ['00000005M'],\n16             'Y' => ['00000006Y'],\n17             'F' => ['00000007F'],\n18             'P' => ['00000008P'],\n19             'D' => ['00000009D'],\n20             'X' => ['00000010X'],\n21             'B' => ['00000011B'],\n22             'N' => ['00000012N'],\n23             'J' => ['00000013J'],\n24             'Z' => ['00000014Z'],\n25             'S' => ['00000015S'],\n26             'Q' => ['00000016Q'],\n27             'V' => ['00000017V'],\n28             'H' => ['00000018H'],\n29             'L' => ['00000019L'],\n30             'C' => ['00000020C'],\n31             'K' => ['00000021K'],\n32             'E' => ['00000022E']\n33         ];\n34     }\n

\n\n\n\n

Lo esperable es que fallen todos los casos menos el primero que, de hecho, tenemos repetido, por lo que podemos borrarlo ahora que no lo necesitamos.

\n\n

Después de un rato trabajando, tendremos una implementación más o menos como esta:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     private const NIF_FORMAT = '/^[\\dxyz]\\d{7,7}[a-z]$/i';\n 5 \n 6     private const CONTROL_DIGITS = 'trwagmyfpdxbnjzsqvhlcke';\n 7 \n 8     public function do(string $nif) : bool\n 9     {\n10         $nif = strtolower($nif);\n11 \n12         if (!preg_match(self::NIF_FORMAT, $nif)) {\n13             return false;\n14         }\n15 \n16         $modulus = ((int) substr($nif, 0, 8)) % 23;\n17 \n18         if (substr($nif, -1) === self::CONTROL_DIGITS[$modulus]) {\n19             return true;\n20         }\n21 \n22         return false;\n23     }\n24 }\n

\n\n\n\n

Este código pasa todos los tests. Es muy mejorable, especialmente en cuanto a legibilidad.

\n\n

Además nos falta cubrir varios casos más, como los números de NIE, que tendrían este formato: ‘X0000000T’. En realidad el algoritmo no cambia mucho, sólo hay que reemplazar las letras X, Y, Z por los números 0, 1, 2, respectivamente.

\n\n

Hagamos un test que pruebe que podemos dar como válidos NIE correctos:

\n\n

 1     /** @dataProvider validNIES */\n 2     public function testShouldBeValidNies($nif)\n 3     {\n 4         $this->assertTrue($this->validateNif->do($nif));\n 5     }\n 6 \n 7     public function validNIES()\n 8     {\n 9         return [\n10             'XT' => ['X0000000T'],\n11             'YZ' => ['Y0000000Z'],\n12             'ZM' => ['Z0000000M']\n13         ];\n14     }\n

\n\n\n\n

El código que pasa este test, en principio es el siguiente:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     private const NIF_FORMAT = '/^[\\dxyz]\\d{7,7}[a-z]$/i';\n 5 \n 6     private const CONTROL_DIGITS = 'trwagmyfpdxbnjzsqvhlcke';\n 7 \n 8     public function do(string $nif) : bool\n 9     {\n10         $nif = strtolower($nif);\n11 \n12         if (!preg_match(self::NIF_FORMAT, $nif)) {\n13             return false;\n14         }\n15 \n16         $numberPart = substr($nif, 0, 8);\n17         $numberPart = str_replace(['x', 'y', 'z'], [0, 1, 2], $numberPart);\n18         $modulus = ((int) $numberPart) % 23;\n19 \n20         if (substr($nif, -1) === self::CONTROL_DIGITS[$modulus]) {\n21             return true;\n22         }\n23 \n24         return false;\n25     }\n26 }\n

\n\n\n\n

Y como es sobradamente feo vamos a intentar arreglarlo un poco, cosa que podemos hacer con seguridad pues tenemos cobertura total de test. Extraeremos algunos métodos para ello:

\n\n

 1 class ValidateNif\n 2 {\n 3 \n 4     private const NIF_FORMAT = '/^[\\dxyz]\\d{7,7}[a-z]$/i';\n 5     private const CONTROL_DIGITS = 'trwagmyfpdxbnjzsqvhlcke';\n 6     private const MAGIC_DIVISOR = 23;\n 7     private const NIE_STARTING_LETTERS = ['x', 'y', 'z'];\n 8     private const NIE_STARTING_LETTERS_REPLACEMENTS = [0, 1, 2];\n 9     \n10     public function do(string $nif) : bool\n11     {\n12         $nif = strtolower($nif);\n13 \n14         if (!$this->nifHasTheRightFormat($nif)) {\n15             return false;\n16         }\n17 \n18         if ($this->controlDigitIsCorrect($nif)) {\n19             return true;\n20         }\n21 \n22         return false;\n23     }\n24 \n25     private function nifHasTheRightFormat(string $nif)\n26     {\n27         return preg_match(self::NIF_FORMAT, $nif);\n28     }\n29     \n30     private function controlDigitIsCorrect(string $nif) : bool\n31     {\n32         $modulus = $this->calculateModulusOfNumberPart($nif);\n33 \n34         return substr($nif, -1) === self::CONTROL_DIGITS[ $modulus ];\n35     }\n36 \n37     private function calculateModulusOfNumberPart(string $nif) : int\n38     {\n39         $numberPart = str_replace(\n40             self::NIE_STARTING_LETTERS,\n41             self::NIE_STARTING_LETTERS_REPLACEMENTS,\n42             substr($nif, 0, 8)\n43         );\n44         $modulus = ((int) $numberPart) % self::MAGIC_DIVISOR;\n45 \n46         return $modulus;\n47     }\n48 }\n

\n\n\n\n

Nos queda pendiente el caso de las letras que no son válidas como letras de NIF. ¿Qué crees que pasará?

\n\n

 1     /** @dataProvider invalidNIFS */\n 2     public function testInvalidLetters($nif)\n 3     {\n 4         $this->assertFalse($this->validateNif->do($nif));\n 5     }\n 6 \n 7     public function invalidNIFS()\n 8     {\n 9         return [\n10             'I' => ['00000000I'],\n11             'O' => ['00000000O'],\n12             'U' => ['00000000U'],\n13             'Ñ' => ['00000000Ñ']\n14         ];\n15     }\n

\n\n\n\n

Pues que el caso ya estaba resuelto por nuestra implementación.

\n\n

Concluyendo

\n\n

Podríamos hacer una implementación mucho más compacta, aunque también bastante ilegible. Sin embargo, lo interesante del ejercicio es haber practicado como hacer TDD de un método que devuelve valores booleanos.

\n\n

El truco está en comenzar con un test que espera uno de los dos valores y, seguidamente, probar todos los casos que provoquen el valor opuesto.

\n\n\n

Desarrollar un algoritmo paso a paso con TDD: Luhn Test kata

\n\n

Originalmente, hice esta kata con php en el blog, pero voy a trasponerla a PHP para este capítulo. Los principios en que se basa son exactamente los mismos, pero he tratado de eliminar todas las referencias a php y a como organizar el entorno de trabajo en ese lenguaje.

\n\n

Sobre la Luhn Test kata

\n\n

La idea es desarrollar una función que testee números de tarjetas de crédito para ver si son válidos o simplemente cifras escogidas al azar.

\n\n

Puedes ver el ejercicio y sus detalles en este Gist de Manuel Rivero, quien presentó la kata en uno de los meetups de la Software Crafters de Barcelona, con una complejidad añadida: crear una única función o método para hacer la validación, testeando únicamente la interfaz pública y hacerlo en baby-steps.

\n\n

Esto significa no recurrir a objetos colaboradores, que podrían testearse aisladamente, o a trampear los tests probando métodos privados o similar. También significa no generar todo el algoritmo en una primera iteración, sino forzarse a ir paso a paso.

\n\n

Tiene su miga y eso es lo que voy a intentar hacer en este artículo.

\n\n

Empecemos con un test

\n\n

Lo primero es empezar con un test, así que voy a crear un primer archivo que llamaré LuhnValidatorTest.php.

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Tests\\Dojo\\Luhn;\n 5 \n 6 use Dojo\\Luhn\\LuhnValidator;\n 7 use PHPUnit\\Framework\\TestCase;\n 8 \n 9 class LuhnValidatorTest extends TestCase\n10 {\n11     public function testShouldValidateAllZeros(): void\n12     {\n13         $validator = new LuhnValidator();\n14         $this->assertTrue($validator->isValid('00000000000'));\n15     }\n16 }\n

\n\n\n\n

Voy a explicar este test y cómo lo he hecho.

\n\n

Analizar el problema y escoger el primer test

\n\n

Escoger el primer test en TDD es siempre un pequeño reto y resolverlo es algo que se perfecciona con la práctica y examinando el problema que tenemos entre manos. También es cierto que el propio proceso de TDD suele confirmarte si lo has escogido bien o tienes que replantearlo.

\n\n

Una aclaración: no voy a considerar toda la problemática de validar la longitud de la cadena que se pasa como argumento, ni otras consideraciones que haría en un caso “real”, así nos centramos en el meollo de este ejercicio.

\n\n

En cuanto al test en sí, en este ejercicio es importante pensar en cómo funciona el algoritmo de validación. Los puntos importantes son:

\n\n

El dato de entrada es una cadena de 11 dígitos.
Primero, se invierte la cadena de números.
Después se toman los que ocupan las posiciones pares e impares y se tratan por separado.
El grupo de los impares simplemente se suma.
El grupo de los pares, se multiplica por dos, se suman los dígitos de los resultados entre sí, si son mayores que 10, y lo que sale se acumula.
Luego se suma lo obtenido de los números impares y pares.
Si el resultado es múltiplo de 10 (esto es: acaba en cero) entonces el número de tarjeta ingresado es válido.

\n\n

Al analizar este flujo podemos ver que las operaciones son sumas y productos y, siendo los productos una suma de sumandos iguales, tenemos una cifra interesante para empezar a trabajar que es el 0, elemento neutro de la suma de enteros. Un número de tarjeta compuesto sólo por ceros será válido porque la serie de cálculos realizados dará cero como resultado. Por tanto es ideal como primer test, que nos forzará a crear la clase y el método.

\n\n

Empezando con el código de producción

\n\n

El test que he mostrado arriba no pasará obviamente. Primero nos reclama crear la clase LuhnValidator.

\n\n

Código mínimo para pasar el test

\n\n

Helo aquí, en LuhnValidator.php:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11     }\n12 }\n

\n\n\n\n

Claro que esto no pasará el test pero, de momento, nos garantiza que hemos implementado lo mínimo necesario. Simplemente nos falta hacer que devuelva algo:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         return true;\n12     }\n13 }\n

\n\n\n\n

Y ahora el test pasa.

\n\n

Buscando un nuevo ejemplo

\n\n

Tenemos que volver al enunciado del problema. Lo primero que tenemos que hacer con la cadena entrante es invertirla, así que sería buena idea disponer de un test que de alguna manera pruebe que la hemos invertido.

\n\n

Eso descarta números de tarjeta con todos los dígitos iguales o formando palíndromos: queremos algo que cambie al invertir su orden y que sea lo más sencillo posible.

\n\n

Nuestro primer test nos forzó a implementar algo muy básico: el validador siempre devuelve true, así que nos conviene que el siguiente ejemplo no sea válido, lo que nos forzará a implementar un mínimo del algoritmo. En realidad dos cosas:

\n\n

La inversión de los dígitos
Una pequeña parte del algoritmo

\n\n

Y esto es lo que tenemos:

\n\n

La inversión de los dígitos se puede forzar si el número de la tarjeta de crédito es asimétrico, por ejemplo, todos los dígitos son iguales menos uno en un extremo.
Lo más sencillo es operar con los dígitos que tras la inversión queden en las posiciones impares, ya que sólo habría que sumarlos.
Los dígitos que caigan en lugar par tendré que multiplicarlos por dos, y lo ideal, de momento, es que sean menores a cinco para no tener que hacer la suma de los dígitos resultantes.
Los dígitos que sean cero no van a influir en el cálculo, por lo que puedo dejar en cero todos los dígitos que no necesite.
Si a esto le añado que los dígitos finales del original acabarán en las primeras posiciones de la secuencia invertida…

\n\n

Mi siguiente ejemplo será: “00000000001”.

\n\n

Pero, un momento, ¿sería un número válido o no? Hemos quedado en que no puede serlo.

\n\n

Lo cierto es que si aplicamos el algoritmo vemos que nuestro ejemplo no sería válido, por lo tanto, nuestro un test en el estado actual del código no pasaría, que es lo que queremos.

\n\n

¿Y por qué este ejemplo en concreto y no otro?

\n\n

Bien, mi interés es probar que invertimos el número de tarjeta introducido, así que voy a implementar un test que asegure que si sólo tomo en consideración el primer dígito tras la inversión éste no es cero y, por tanto, la cadena ha sido invertida. Si sólo tomo el primer dígito en consideración y los demás son ceros, el resultado de la suma total que necesitamos para valorar si la tarjeta es válida será igual a ese primer dígito.

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Tests\\Dojo\\Luhn;\n 5 \n 6 use Dojo\\Luhn\\LuhnValidator;\n 7 use PHPUnit\\Framework\\TestCase;\n 8 \n 9 class LuhnValidatorTest extends TestCase\n10 {\n11     public function testShouldValidateAllZeros(): void\n12     {\n13         $validator = new LuhnValidator();\n14         $this->assertTrue($validator->isValid('00000000000'));\n15     }\n16 \n17     public function testShouldNotValidateAllZerosEndingInOne(): void\n18     {\n19         $validator = new LuhnValidator();\n20         $this->assertFalse($validator->isValid('00000000001'));\n21     }\n22 }\n

\n\n\n\n

El test falla, por lo que vamos a implementar.

\n\n

Lo primero es invertir la cadena, cosa que en PHP se puede hacer así:

\n\n

1 $inverted = strrev($luhnCode);\n

\n\n\n

Pero esto no hace pasar el test, hay que implementar una mínima parte del algoritmo, que simplemente es ver el valor del primer dígito de la cadena invertida. Si no es 0 devolvemos False porque sería inválido:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12         if ($inverted[0] !== '0') {\n13             return false;\n14         }\n15         return true;\n16     }\n17 }\n

\n\n\n\n

Este ha sido un primer paso, y puede que no sea suficiente para demostrar todo lo que queremos. Pero lo interesante es que estamos avanzando en pequeños pasos, que es la intención del ejercicio.

\n\n

Tal cual está el código en este momento no tendríamos por qué hacer mucho más. A primera vista tendríamos la opción de realizar un pequeño refactor:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         return !($inverted[0] !== '0');\n14     }\n15 }\n

\n\n\n\n

Los tests deben forzar implementaciones

\n\n

Una premisa de TDD es que cualquier código de producción sólo puede crearse como respuesta a un test que falle, que es como decir a una característica no implementada todavía. Si ahora escribimos un nuevo test que pase no podríamos modificar la implementación. No es que esté “prohibido”, es simplemente que en este momento si escribimos un nuevo test que pasa, no nos dice nada acerca de qué deberíamos implementar. Únicamente nos confirma lo que ya sabemos. En todo caso, este tipo de tests, que recién escrito ya pasa, nos puede servir como test de regresión: si algún día falla nos está indicando que algo está alterando el algoritmo.

\n\n

Lo que nos interesa ahora mismo es introducir alguna variación en los ejemplos que fuerce un cambio en la implementación a fin de darle cobertura. En concreto queremos sumar los dígitos en las posiciones impares.

\n\n

Un enfoque sería añadir un nuevo dígito que caiga en posición impar al invertir la cadena, pero que cambie el resultado de la validación, de modo que el número de tarjeta sea válido. Eso quiere decir que los dígitos que introduzcamos deben sumar diez.

\n\n

Un ejemplo es “00000000901”, pero también valdrían otros como “00000000604”, o “00000000208”.

\n\n

Sin embargo, hay un test mucho más sencillo. Bastaría con poner 1 en la siguiente posición que nos interesa: “00000000100”. Si el algoritmo no tiene en cuenta esa posición el test fallará y para hacerlo pasar habrá que introducirla en el cálculo:

\n\n

He aquí el test:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Tests\\Dojo\\Luhn;\n 5 \n 6 use Dojo\\Luhn\\LuhnValidator;\n 7 use PHPUnit\\Framework\\TestCase;\n 8 \n 9 class LuhnValidatorTest extends TestCase\n10 {\n11     public function testShouldValidateAllZeros(): void\n12     {\n13         $validator = new LuhnValidator();\n14         $this->assertTrue($validator->isValid('00000000000'));\n15     }\n16 \n17     public function testShouldNotValidateAllZerosEndingInOne(): void\n18     {\n19         $validator = new LuhnValidator();\n20         $this->assertFalse($validator->isValid('00000000001'));\n21     }\n22 \n23     public function testShouldNotValidateOneInThirdPositionFromEnding(): void\n24     {\n25         $validator = new LuhnValidator();\n26         $this->assertFalse($validator->isValid('00000000100'));\n27     }\n28 }\n

\n\n\n\n

Después de asegurarme de que el test no pasa, vamos al código de producción.

\n\n

El problema es que tengo dos opciones: por un lado, de momento me basta con controlar que cualquiera las dos posiciones tiene un dígito distinto de cero para pasar este test concreto.

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         return !($inverted[0] !== '0' || $inverted[2] !== '0');\n14     }\n15 }\n

\n\n\n\n

En otras palabras: el test anterior no me ha forzado a implementar la suma, ya que podría cubrirlo con otro algoritmo. Por eso, ahora es cuando hago un test que pruebe que dos dígitos que sumen 10 hacen un número de tarjeta válido:

\n\n

1     public function testShouldValidateWithTwoNoZerosAddingTen(): void\n2     {\n3         $validator = new LuhnValidator();\n4         $this->assertTrue($validator->isValid('00000000406'));\n5     }\n

\n\n\n\n

Y el test falla, porque mi algoritmo no suma los dígitos que han caído en posiciones impares. Lo que me interesa es empezar a sumarlos, y lo más fácil es acumular directamente las dos posiciones que me interesan. Como puedo ignorar el resto de dígitos al ser cero, no tengo más que ver si el resultado es divisible por 10.

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $inverted[0] + $inverted[2];\n14         \n15         if ($oddAdded % 10 === 0) {\n16             return true;\n17         }\n18         \n19         return false;\n20     }\n21 }\n

\n\n\n\n

En este ejemplo, que hace pasar el test, también vemos una oportunidad de refactor:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $inverted[0] + $inverted[2];\n14 \n15         return $oddAdded % 10 === 0;\n16     }\n17 }\n

\n\n\n\n

Buscando un algoritmo más general

\n\n

Todavía no tenemos mucho para forzarnos a escribir un algoritmo más general. Para eso necesitamos otro test, el cual debe fallar si queremos que nos sirva. El código nos pedirá un algoritmo más general cuando podamos observar repeticiones o algún tipo de regularidad que podamos expresar de otra manera.

\n\n

Nosotros vamos a proponer el siguiente test, que nos fuerza a considerar un tercer dígito en la validación. Ahora que ya he establecido que el algoritmo se basa en la suma, puedo volver a mi estrategia minimalista anterior. He aquí el ejemplo (a partir de ahora sólo voy a poner el test específico). Aprovecho para cambiar un poco la forma de denominar los tests para que sean más claros sobre lo que ocurre

\n\n

1     public function testShouldConsiderFifthPosition(): void\n2     {\n3         $validator = new LuhnValidator();\n4         $this->assertFalse($validator->isValid('00000010000'));\n5     }\n

\n\n\n\n

Este test no pasa porque el algoritmo no tiene en cuenta todavía la quinta posición. Así que toca implementar algo:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8     public function isValid(string $luhnCode) : bool\n 9     {\n10         $inverted = strrev($luhnCode);\n11 \n12         $oddAdded = $inverted[0] + $inverted[2] + $inverted[4];\n13 \n14         return $oddAdded % 10 === 0;\n15     }\n16 }\n

\n\n\n\n

Con este cambio, el test pasa. Y lo bueno es que ya empezamos a vislumbrar una posibilidad de refactor: el cálculo de la suma de los dígitos impares (que en la representación index0 de los arrays de PHP van en los lugares pares, para liarla más) empieza a ser difícil de leer, además de repetitivo. Podríamos empezar extrayéndolo a un método, para explicitarlo:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $this->addOddDigits($inverted);\n14 \n15         return $oddAdded % 10 === 0;\n16     }\n17 \n18     private function addOddDigits(string $inverted): int\n19     {\n20         return $inverted[0] + $inverted[2] + $inverted[4];\n21     }\n22 }\n

\n\n\n\n

En principio, podríamos seguir haciendo baby steps hasta cubrir todas las posiciones impares una a una hasta el total de seis, añadiendo un test para cada posición, pero a estas alturas ya parece obvio que podemos generalizar el método de cálculo con un bucle. En este ejercicio mostraré los tests uno a uno y el código de producción final. En un caso de trabajo real el tamaño de los baby steps puede modularse en la medida en que tengamos seguridad de cuál es la implementación más obvia en cada momento.

\n\n

He aquí los tests con la nueva nomenclatura. La clave es que cada uno debe hacerse teniendo en cuenta lo que tenemos hasta ese momento:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Tests\\Dojo\\Luhn;\n 5 \n 6 use Dojo\\Luhn\\LuhnValidator;\n 7 use PHPUnit\\Framework\\TestCase;\n 8 \n 9 class LuhnValidatorTest extends TestCase\n10 {\n11     public function testShouldValidateAllZeros(): void\n12     {\n13         $validator = new LuhnValidator();\n14         $this->assertTrue($validator->isValid('00000000000'));\n15     }\n16 \n17     public function testShouldConsiderFirstPosition(): void\n18     {\n19         $validator = new LuhnValidator();\n20         $this->assertFalse($validator->isValid('00000000001'));\n21     }\n22 \n23     public function testShouldConsiderThirdPosition(): void\n24     {\n25         $validator = new LuhnValidator();\n26         $this->assertFalse($validator->isValid('00000000100'));\n27     }\n28 \n29     public function testShouldValidateTwoEvenPositionsAddingTen(): void\n30     {\n31         $validator = new LuhnValidator();\n32         $this->assertTrue($validator->isValid('00000000406'));\n33     }\n34 \n35     public function testShouldConsiderFifthPosition(): void\n36     {\n37         $validator = new LuhnValidator();\n38         $this->assertFalse($validator->isValid('00000010000'));\n39     }\n40 \n41     public function testShouldConsiderSeventhPosition(): void\n42     {\n43         $validator = new LuhnValidator();\n44         $this->assertFalse($validator->isValid('00001000000'));\n45     }\n46 \n47     public function testShouldConsiderNinthPosition(): void\n48     {\n49         $validator = new LuhnValidator();\n50         $this->assertFalse($validator->isValid('00100000000'));\n51     }\n52 \n53     public function testShouldConsiderEleventhPosition(): void\n54     {\n55         $validator = new LuhnValidator();\n56         $this->assertFalse($validator->isValid('10000000000'));\n57     }\n58 }\n

\n\n\n\n

Y este es el código de producción, que es bastante feo pero pasa.

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $this->addOddDigits($inverted);\n14 \n15         return $oddAdded % 10 === 0;\n16     }\n17 \n18     private function addOddDigits(string $inverted) : int\n19     {\n20         return $inverted[0]\n21             + $inverted[2]\n22             + $inverted[4]\n23             + $inverted[6]\n24             + $inverted[8]\n25             + $inverted[10];\n26     }\n27 }\n

\n\n\n\n

Es hora de hacer un refactor, manteniendo los tests en verde:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $this->addOddDigits($inverted);\n14 \n15         return $oddAdded % 10 === 0;\n16     }\n17 \n18     private function addOddDigits(string $inverted) : int\n19     {\n20         $oddAdded = 0;\n21         for ($position = 0; $position < 11; $position += 2) {\n22             $oddAdded += $inverted[$position];\n23         }\n24         return $oddAdded;\n25     }\n26 }\n

\n\n\n\n

Y con esto, ya tenemos dos partes del algoritmo cubiertas. Tendremos que trabajar ahora con las posiciones pares.

\n\n

Añadiendo prestaciones

\n\n

Las posiciones pares nos plantean varios problemas:

\n\n

Primero tenemos que multiplicar cada dígito por dos.
En caso de que el resultado sea mayor que diez debemos sumar los dígitos resultantes.
Por ultimo, debemos sumar todo lo obtenido.

\n\n

Y, para finalizar, sumaremos el resultado a la suma de los dígitos en posición impar, para decidir si el número de tarjeta es válido.

\n\n

Sin embargo, podríamos desmenuzar el problema de una forma parecida a la anterior. Por una parte, necesitamos ignorar las posiciones impares, por lo que las pondremos a cero en nuestros casos de ejemplo. Utilizar como dígito para las pruebas el 1 parece una buena idea, ya que no nos obliga a implementar, de momento, la fase de reducir el resultado si es mayor que diez.

\n\n

Así que haremos un test para empezar:

\n\n

1     public function testShouldConsiderSecondPosition(): void\n2     {\n3         $validator = new LuhnValidator();\n4         $this->assertFalse($validator->isValid('00000000010'));\n5     }\n

\n\n\n\n

El test falla, implementemos algo para pasar el test:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $this->addOddDigits($inverted);\n14         $evenAdded = $inverted[1] * 2;\n15 \n16         return ($oddAdded + $evenAdded) % 10 === 0;\n17     }\n18 \n19     private function addOddDigits(string $inverted) : int\n20     {\n21         $oddAdded = 0;\n22         for ($position = 0; $position < 11; $position += 2) {\n23             $oddAdded += $inverted[$position];\n24         }\n25         return $oddAdded;\n26     }\n27 }\n

\n\n\n\n

Podemos seguir usando el mismo patrón que antes, moviendo el dígito a la siguiente posición par, un test cada vez. Para abreviar el ejemplo, voy a poner sólo los tests que he ido haciendo (te doy mi palabra de que he llegado hasta aquí haciendo baby steps):

\n\n

 1     public function testShouldConsiderSecondPosition(): void\n 2     {\n 3         $validator = new LuhnValidator();\n 4         $this->assertFalse($validator->isValid('00000000010'));\n 5     }\n 6 \n 7     public function testShouldConsiderFourthPosition(): void\n 8     {\n 9         $validator = new LuhnValidator();\n10         $this->assertFalse($validator->isValid('00000001000'));\n11     }\n12 \n13     public function testShouldConsiderSixthPosition(): void\n14     {\n15         $validator = new LuhnValidator();\n16         $this->assertFalse($validator->isValid('00000100000'));\n17     }\n18 \n19     public function testShouldConsiderEighthPosition(): void\n20     {\n21         $validator = new LuhnValidator();\n22         $this->assertFalse($validator->isValid('00010000000'));\n23     }\n24 \n25     public function testShouldConsiderTenthPosition(): void\n26     {\n27         $validator = new LuhnValidator();\n28         $this->assertFalse($validator->isValid('01000000000'));\n29     }\n30         self.assertFalse(luhn_validator.is_valid('01000000000'))\n

\n\n\n\n

Y este es el código que estos tests me han permitido escribir, una vez refactorizado:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $this->addOddDigits($inverted);\n14         $evenAdded = $this->addEvenDigits($inverted);\n15 \n16         return ($oddAdded + $evenAdded) % 10 === 0;\n17     }\n18 \n19     private function addOddDigits(string $inverted) : int\n20     {\n21         $oddAdded = 0;\n22         for ($position = 0; $position < 11; $position += 2) {\n23             $oddAdded += $inverted[ $position ];\n24         }\n25 \n26         return $oddAdded;\n27     }\n28 \n29     private function addEvenDigits(string $inverted)\n30     {\n31         $evenAdded = 0;\n32         for ($position = 1; $position < 11; $position += 2) {\n33             $evenAdded += $inverted[ $position ] * 2;\n34         }\n35 \n36         return $evenAdded;\n37     }\n38 }\n

\n\n\n\n

Nos queda un requisito por implementar. Si el doble de los dígitos pares es mayor o igual que diez tenemos que sumar los dígitos de este producto y sumar éste en su lugar. Por tanto tendríamos que hacer test con algún ejemplo que fuerce esa situación y nos obligue a implementar.

\n\n

Por ejemplo, el caso “00000000050” debería darnos un número no válido, según prueba este test:

\n\n

1     def test_credit_card_with_only_second_digit_five_is_invalid(self):\n2         luhn_validator = LuhnValidator()\n3         self.assertFalse(luhn_validator.is_valid('00000000050'))\n

\n\n\n\n

Y falla porque el doble de cinco es 10, lo que fuerza al método a devolver true. Si sumamos los dígitos, el resultado sería 1, lo que hace fallar la validación y, por tanto, hace pasar nuestro test.

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $this->addOddDigits($inverted);\n14         $evenAdded = $this->addEvenDigits($inverted);\n15 \n16         return ($oddAdded + $evenAdded) % 10 === 0;\n17     }\n18 \n19     private function addOddDigits(string $inverted) : int\n20     {\n21         $oddAdded = 0;\n22         for ($position = 0; $position < 11; $position += 2) {\n23             $oddAdded += $inverted[ $position ];\n24         }\n25 \n26         return $oddAdded;\n27     }\n28 \n29     private function addEvenDigits(string $inverted)\n30     {\n31         $evenAdded = 0;\n32         for ($position = 1; $position < 11; $position += 2) {\n33             $double = $inverted[ $position ] * 2;\n34             if ($double >= 10) {\n35                 $double = intdiv($double, 10) + $double % 10;\n36             }\n37             $evenAdded += $double;\n38         }\n39 \n40         return $evenAdded;\n41     }\n42 }\n

\n\n\n\n

Es un código bastante feo, pero hace su trabajo.

\n\n

Podríamos mejorarlo un poco, aprovechando que nos cubren los tests:

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Dojo\\Luhn;\n 5 \n 6 class LuhnValidator\n 7 {\n 8 \n 9     public function isValid(string $luhnCode) : bool\n10     {\n11         $inverted = strrev($luhnCode);\n12 \n13         $oddAdded = $this->addOddDigits($inverted);\n14         $evenAdded = $this->addEvenDigits($inverted);\n15 \n16         return ($oddAdded + $evenAdded) % 10 === 0;\n17     }\n18 \n19     private function addOddDigits(string $inverted) : int\n20     {\n21         $oddAdded = 0;\n22         for ($position = 0; $position < 11; $position += 2) {\n23             $oddAdded += (int) $inverted[ $position ];\n24         }\n25 \n26         return $oddAdded;\n27     }\n28 \n29     private function addEvenDigits(string $inverted) : int\n30     {\n31         $evenAdded = 0;\n32         for ($position = 1; $position < 11; $position += 2) {\n33             $double = (int) $inverted[ $position ] * 2;\n34             $evenAdded += $this->reduceToOneDigit($double);\n35         }\n36 \n37         return $evenAdded;\n38     }\n39 \n40     private function reduceToOneDigit($double) : int\n41     {\n42         if ($double >= 10) {\n43             $double = intdiv($double, 10) + $double % 10;\n44         }\n45 \n46         return $double;\n47     }\n48 }\n

\n\n\n\n

Tenemos 14 tests que prueban pequeñas partes de nuestro algoritmo. Es hora de asegurarnos de que todo funciona correctamente. Podríamos probar con el ejemplo propuesto en la kata. Actuaría como test de aceptación. De hecho, podría haberlo escrito desde el primer momento. Aquí está en ** LuhnValidatorAcceptanceTest.php**

\n\n

 1 <?php\n 2 declare (strict_types=1);\n 3 \n 4 namespace Tests\\Dojo\\Luhn;\n 5 \n 6 use Dojo\\Luhn\\LuhnValidator;\n 7 use PHPUnit\\Framework\\TestCase;\n 8 \n 9 class LuhnValidatorAcceptanceTest extends TestCase\n10 {\n11     public function testShouldValidateRealCardNumber(): void\n12     {\n13         $validator = new LuhnValidator();\n14         $this->assertTrue($validator->isValid('49927398716'));\n15     }\n16 }\n

\n\n\n\n

¿Y sabes qué? El test pasa.

\n\n

Y es interesante reflexionar sobre cómo el hecho de desarrollar con TDD y buenos tests de aceptación mejora el tiempo de desarrollo disminuyendo la necesidad de tratar con defectos del código que se nos podrían haber escapado de no disponer de tests.

\n\n\n

Clean testing

\n\n

Los tests también son código. así que igualmente tenemos que mantenerlos legibles y, por tanto, más capaces de comunicar lo que hace el software que respaldan.

\n\n

Escribo bastantes tests en mi trabajo y tiendo a hacerlo en modo TDD siempre que puedo. Aún así, no estoy especialmente orgulloso de mis tests, pienso que tengo un gran espacio de mejora en esa área. Hay dos aspectos que me preocupan en particular:

\n\n

El primero es la constatación de que todavía se me escapan bastantes casos, sobre todo en la integración, que acaban dando lugar a defectos en el software. Sobre esto tengo que pensar más a fondo y adoptar mejores estrategias de diseño.
El segundo tiene que ver con la calidad del código de los tests. Al fin y al cabo los tests siguen siendo código y debería aplicar los principios de diseño y las buenas prácticas para que sean sostenibles, legibles y útiles. Es más, en mi opinión, deberían ser legibles incluso para alguien que no conozca el lenguaje de programación.

\n\n

De este segundo aspecto es de lo que trata este capítulo, en el que intento recoger algunas ideas con las que estoy trabajando últimamente.

\n\n

Buena parte de esto se apoya en la charla Be solid my tests de mi compañera y team lead en HolaLuz, Mavi Jiménez, que explica muy bien por qué y cómo nuestros tests tienen que ser SOLID, además de sólidos, y propone algunas técnicas prácticas para lograrlo.

\n\n

Después de ver la charla, puedes seguir leyendo.

\n\n

Naming de los test

\n\n

Cada vez más, intento escribir tests cuyo nombre pueda leerse incluso sin saber programación, de modo que pueda entender qué es lo que se prueba y facilitar así la vida de mi yo del futuro y de compañeras y compañeros que tengan que enfrentarse a ese código.

\n\n

Puede parecer que el nombre de los tests no tenga importancia. Sin embargo, es un aspecto clave del test en el que declaramos qué es lo que estamos probando en lenguaje de negocio. Así que, aunque comencemos con nombres tentativos, debemos crearlo con mucho cuidado y asegurarnos de que realmente dice lo que queremos demostrar con él.

\n\n

Usar abstracciones

\n\n

Por ejemplo, el siguiente test dice que la clase o método probados no debería aceptar cadenas de más de un cierto número de caracteres.

\n\n

1 // Not so good\n2 \n3 public function testShouldNotAcceptStringsLongerThanNineCharacters()\n4 \n5 // Better\n6 \n7 public function testShouldNotAcceptStringsLongerThanAMaximumOfCharacters()\n

\n\n\n\n

La razón por la que no pongo un número concreto es que ese número es un detalle que podría cambiar. En la formulación better hablo de un concepto en lugar de una concreción por lo que el enunciado del test se seguiría cumpliendo incluso si el máximo cambiase o fuese configurable.

\n\n

En lo posible evito introducir detalles técnicos, aunque a veces es complicado, como en el caso anterior en el que menciono String, pero prefiero escribir tests que no revelen la implementación.

\n\n

Supongamos un repositorio de estudiantes en una aplicación de gestión educativa:

\n\n

1 // Not so good\n2 \n3 public function testFindAllByClass()\n4 \n5 // Better\n6 \n7 public function testShouldRetrieveStudentsInAGivenClass()\n

\n\n\n\n

El caso Not so good tiene dos defectos principales:

\n\n

En primer lugar dice que se prueba el método FindAllByClass, lo que asume que existe ese método. Si en algún momento cambiamos el nombre del mismo, el test empezará a mentir.
En segundo lugar, no dice qué se espera que suceda, lo cual es la razón de ser del test. Tan sólo dice que se prueba, tanto da que devuelva estudiantes, como chorizos o billetes de metro.

\n\n

El caso Better ataca ambos problemas:

\n\n

No se ata a ninguna implementación particular del método.
Dice lo que debería estar ocurriendo si el test pasa.

\n\n

Los tests dicen lo que debería ocurrir

\n\n

El uso de Should como elemento del nombre del test merece su mención. De hecho me gustaría poder eliminar el prefijo test, que es lo que hace que los test frameworks PHPUnit identifique los métodos que se tienen que ejecutar. Hay un par de soluciones:

\n\n

Usar anotaciones:

\n\n

1 /** @test */\n2 public function shouldRetrieveStudentsInAGivenClass()\n

\n\n\n\n

Configurar un prefijo alternativo mediante un add-on para PHPUnit, que tampoco me convence porque la convención está muy establecida, de modo que pudiese escribir lo anterior sin anotaciones:

\n\n

1 public function shouldRetrieveStudentsInAGivenClass()\n

\n\n\n\n

En este mismo sentido, me gusta la sintaxis de phpspec, que usa it como prefijo, lo que es más natural que test:

\n\n

1 public function it_should_create_a_user_from_retrieved_data();\n

\n\n\n\n

En cualquier caso, me gusta Should como prefijo porque significa “debería”, indicando que la unidad probada debería hacer algo y, por tanto, si no lo hace es que está mal.

\n\n

1 public function testShouldCalculateTheDiscountedPrice()\n

\n\n\n\n

He visto alguna propuesta de utilizar Should como sufijo en el nombre del TestCase, cosa que no estoy seguro de que pudiese funcionar en PHPUnit, pero hay que reconocer que molaría:

\n\n

1 class MyClassShould extends TestCase\n2 {\n3     /** @test */\n4     public function doThatThing()\n5     {\n6         // given, when, then code...\n7     }\n8 }\n

\n\n\n\n

Los tests certifican que cumplimos las reglas de negocio

\n\n

Otra estrategia de naming que me gusta tiene que ver con el cumplimiento de las reglas de negocio y de las invariantes.

\n\n

Es decir, deberíamos tener un test que verifique que se cumplen las reglas de negocio que definen lo que nuestros objetos de dominio pueden y no pueden hacer, o los criterios que los hacen válidos.

\n\n

Por ejemplo, este test para una factoría de Commercial es bastante claro:

\n\n

1 public function testShouldNotCreateASCommercialManagerWithoutCommercialAdmin\n2 {\n3 }\n

\n\n\n\n

O este:

\n\n

1 public function testShouldNotAllowNifsLongerThanMaxCharacters\n2 {\n3 }\n

\n\n\n\n

Por tanto, una buena forma de afrontar esto es redactar una checklist de reglas de dominio e invariantes que nos guíe para decidir qué tenemos que testear en un momento dado ¹

\n\n

Eliminar los números mágicos

\n\n

Uno de los defectos que me gustaría evitar en los tests es el de la aparente arbitrariedad de los valores de los ejemplos y su falta de significatividad. Quiero decir que, para alguien que lea el test puede resultar difícil comprender en una primera lectura por qué hemos elegido probar unos valores y no otros y qué significado tienen.

\n\n

Existen técnicas para seleccionar los valores que usamos para nuestros tests, como pueden ser Equivalence Class Partitioning o Boundary Value Analysis, que se utilizan para asegurarnos de que los tests cubren todos los escenarios posibles con el mínimo de pruebas, lo que resuelve el primer problema estableciendo una metodología.

\n\n

Por ejemplo, Equivalence Class Partitioning es una técnica muy simple con la que agrupamos todos los casos posibles en clases de tal modo que todos los valores de una clase serán equivalentes entre sí, por lo que cualquiera de ellos es representativo de la clase en la que está categorizado. En consecuencia, podemos hacer un test para probar cada una de esas clases en lugar de intentar comprobar todos los valores posibles.

\n\n

Imaginemos un sistema de tarificación basado en la edad, bastante habitual en museos y otras instituciones culturales, tal que el precio de una entrada cuesta:

\n\n

Hasta 7 años: 0€
De 8 a 15: 6€
De 16 a 25: 9€
De 26 a 64: 12€
A partir de 65: 10€

\n\n

Esto es: el rango de todas las posibles edades se organiza en cinco clases o categorías y no tenemos más que escoger un ejemplo de cada una de ellas. Obviamente no hace falta probar todos los casos de 0 a 110 años uno por uno.

\n\n

Así que podríamos hacer una tabla de casos como esta:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Clase	Valor	Precio
7 o menos	5	0
8 - 15	10	6
16 - 25	18	9
26 - 64	30	12
65 o más	70	10

\n\n

Y, consecuentemente, podríamos hacer un test como este:

\n\n

1 public function testCalculatesPriceForSevenOrLess()\n2 {\n3     $priceCalculator = new PriceCalculator();\n4     $this->assertEquals(0, $priceCalculator->forAge(5));\n5 }\n

\n\n\n\n

Vale, el test es correcto pero, ¿a que te deja mal sabor de boca?

\n\n

Si pensamos un momento sobre los datos, es fácil ver que podríamos darle un nombre significativo a las clases:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Clase	Intervalo	Valor	Precio
CHILD	7 o menos	5	0
TEEN	8 - 15	10	6
YOUNG	16 - 25	18	9
ADULT	26 - 64	30	12
ELDER	65 o más	70	10

\n\n

Y utilizarlos en todos los elementos del test, aplicando lo que se denomina Lenguaje Ubicuo:

\n\n

 1 public function testCalculatesPriceForAChild()\n 2 {\n 3     $childAge = 5;\n 4     $expectedPrice = 0;\n 5     $priceCalculator = new PriceCalculator();\n 6     $this->assertEquals(\n 7         $expectedPrice, \n 8         $priceCalculator->forAge($childAge)\n 9     );\n10 }\n

\n\n\n\n

Bueno, esto ha mejorado bastante. Ahora el test es mucho más comunicativo. Pero creo que aún quedaría mejor si usamos constantes;

\n\n

1 public function testCalculatesPriceForAChild()\n2 {\n3     $priceCalculator = new PriceCalculator();\n4     $this->assertEquals(\n5         self::PRICE_FOR_CHILDREN, \n6         $priceCalculator->forAge(self::CHILD)\n7     );\n8 }\n

\n\n\n\n

Obviamente podríamos utilizar un Data Provider, aunque eso no elimina lo anterior:

\n\n

 1 /** @dataProvider agePriceProvider */\n 2 public function testCalculatesPriceForAAge(int $ageGroup, int $expectedPrice)\n 3 {\n 4     $priceCalculator = new PriceCalculator();\n 5     $this->assertEquals(\n 6         $expectedPrice, \n 7         $priceCalculator->forAge($ageGroup)\n 8     );\n 9 }\n10 \n11 public function agePriceProvider()\n12 {\n13     return [\n14         'Child' => [self::CHILD, self::PRICE_FOR_CHILDREN],\n15         'Teen' => [self::TEEN, self::PRICE_FOR_TEENS]\n16         //... you see the point\n17     ];\n18 }\n

\n\n\n\n

Extrae métodos, también en tests

\n\n

Otra cosa que me molesta mucho en los tests es todo el código necesario para preparar el escenario que no comunica nada acerca del test mismo. Hace que el test sea difícil de leer e incluso saber qué está pasando realmente.

\n\n

Al fin y al cabo, la estructura básica de un test es bien sencilla:

\n\n

\nGiven: dado un escenario y unos datos iniciales
\nWhen: cuando se ejercita el subject under test
\nThen: entonces tenemos unos efectos

\n\n

Esta estructura debería estar bien visible siempre, aunque hay situaciones (como el ejemplo anterior) en que no es muy explícita. De hecho, podríamos escribir el ejemplo así, para que se revele de una forma un poco más evidente.

\n\n

 1 public function testCalculatesPriceForAChild()\n 2 {\n 3     $priceCalculator = new PriceCalculator();\n 4     \n 5     $priceForAChild = $priceCalculator->forAge(self::CHILD);\n 6     \n 7     $this->assertEquals(\n 8         self::PRICE_FOR_CHILDREN, \n 9         $priceForAChild\n10     );\n11 }\n

\n\n\n\n

Ahora bien, hay situaciones en las que los escenarios no son tan simples y requieren una preparación más elaborada, como cuando construimos test doubles (y eso que en este ejemplo ya hemos sacado la construcción del Test Double a una clase externa):

\n\n

 1 public function testShouldRetrieveStudentsInAGivenClass()\n 2 {\n 3     $studentsRepository = $this->StudentsRepositoryDoubleBuilder()\n 4         ->loadWithFixtureDataFromFile('../students.yml')\n 5         ->assertFindByClass()\n 6         ->build();\n 7         \n 8     $classRepository = $this->classRepositoryDoubleBuilder()\n 9         ->loadWithFixtureDataFromFile('../classes.yml')\n10         ->assertFindByName('Class A')\n11         ->build();\n12             \n13     $getStudentsInClass = new GetStudentsInClass(\n14         $studentsRepository,\n15         $classRepository\n16     );\n17     \n18     $request = new GetStudentsInClassRequest('Class A');\n19     $listOfStudents = $getStudentsInClass->execute($request);\n20     \n21     $this->assertCount(self::STUDENTS_COUNT_IN_CLASS_A, $listOfStudents);\n22 }\n

\n\n\n\n

Aunque el test tampoco es complicado, la preparación del escenario incluyendo la carga de fixtures es un detalle de implementación que no ayuda necesariamente a la comprensión de lo que ocurre.

\n\n

¿Por qué no hacerlo del siguiente modo?

\n\n

 1 public function testShouldRetrieveStudentsInAGivenClass()\n 2 {\n 3     $studentsRepository = $this->prepareStudentRepository();\n 4     $classRepository = $this->prepareClassRepository();\n 5                     \n 6     $getStudentsInClass = new GetStudentsInClass(\n 7         $studentsRepository,\n 8         $classRepository\n 9     );\n10     \n11     $request = new GetStudentsInClassRequest('Class A');\n12     $listOfStudents = $getStudentsInClass->execute($request);\n13     \n14     $this->assertCount(self::STUDENTS_COUNT_IN_CLASS_A, $listOfStudents);\n15 }\n16 \n17 public function prepareStudentsRepository()\n18 {\n19     return $this->StudentsRepositoryDoubleBuilder()\n20         ->loadWithFixtureDataFromFile('../students.yml')\n21         ->assertFindByClass(123)\n22         ->build();\n23 }\n24 \n25 public function prepareClassRepository()\n26 {\n27     return $this->classRepositoryDoubleBuilder()\n28         ->loadWithFixtureDataFromFile('../classes.yml')\n29         ->assertFindByName('Class A')\n30         ->build();\n31 }\n

\n\n\n\n

Lo que hemos hecho ha sido extraer la preparación de los dobles de los repositorios a sus propios métodos, lo que nos permite escribir el test de una forma más concisa y clara.

\n\n

Obviamente, en un proyecto real, es posible que pudiésemos extraer gran parte de la preparación a métodos setUp, incluyendo la instanciación del servicio, o incluso parametrizar de algún modo los métodos prepare*, pero creo que la idea queda clara en cuanto a que el cuerpo del test tenga líneas con un mismo nivel de abstracción ².

\n\n

Esperar excepciones

\n\n

Hace tiempo decidí reducir en lo posible el uso de annotations en el código porque me genera cierta inseguridad. Por esa razón, en vez de marcar un test como que espera excepciones, hago la expectativa de forma explícita en el código:

\n\n

 1 /** @expectException InvalidArgumentException */\n 2 public function testShouldNotAllowTooLongStrings()\n 3 {\n 4     $nif = new NIF(self::TOO_LONG_STRING);\n 5 }\n 6 \n 7 // vs\n 8 \n 9 public function testShouldNotAllowTooLongStrings()\n10 {\n11     $this->expectException(InvalidArgumentException::class);\n12     \n13     $nif = new NIF(self::TOO_LONG_STRING);\n14 }\n

\n\n\n\n

El punto en contra, sobre el que no tengo una opinión del todo consolidada, es dónde poner esa expectativa. Con las anotaciones se sitúa al principio del test, pero la estructura Given->When->Then nos dice que debería estar al final:

\n\n

 1 public function testShouldFailIfStudentDoesNotExist()\n 2 {\n 3     $studentsRepository = $this->prepareStudentRepository();\n 4 \n 5     $getStudentByName = new GetStudentByName(\n 6         $studentsRepository\n 7     );\n 8     \n 9     $request = new GetStudentByNameRequest('Student Name');\n10     \n11     $this->expectException(StudentDoesNotExistException::class);\n12     $student = $getStudentByName->execute($request);\n13 }\n

\n\n\n\n

En parte, me inclino más por la primera opción, precisamente por el carácter de excepcionalidad.

\n\n

Métodos assert

\n\n

De vez en cuando, si necesito hacer una aserción que tiene alguna complejidad o necesita alguna preparación escribo un método con nombre assert para encapsularla. Por ejemplo, este método para comparar dos arrays independientemente del orden:

\n\n

1 protected function assertEqualsArrays($expected, $actual, $message = null)\n2 {\n3     sort($expected);\n4     sort($actual);\n5     $this->assertEquals($expected, $actual, $message);\n6 }\n

\n\n\n\n

Eso me lleva a pensar que algunas triangulaciones en los tests podrían, igualmente, encapsularse en un único método:

\n\n

1 protected function assertValidCommercial(Commercial $commercial)\n2 {\n3     $this->assertEquals(CommercialType::fromString('admin'), $commercial->type());\n4     $this->assertEquals(null, $commercial->parent());\n5     $this->assertEquals([CommercialRole::ROLE_ADMIN], $commercial->getRoles());\n6 }\n

\n\n\n\n\n

Test doubles (1)

\n\n

Estaba pensando en comenzar el artículo con la manida metáfora de los test doubles como especialistas de cine, los que doblan a los actores en ciertas escenas, no necesariamente peligrosas. Pero cuando más vueltas le doy, menos claro tengo que sea un buen símil.

\n\n

Al fin y al cabo, los test doubles son más bien figurantes que, a veces, tienen una o dos líneas de diálogo en la escena, mientras que nuestra unidad bajo test es la protagonista y la que tiene que llevar el peso de la actuación: no la podemos sustituir por otra. En cambio, de los test doubles preferimos que no hagan nada especial y que, si lo hacen, no se salgan del guión ni un milímetro.

\n\n

Así pues, ¿qué son los test doubles?

\n\n

El concepto de test double

\n\n

Comencemos con la idea de test unitario. Un test unitario busca probar que una unidad de software se comporta de la manera deseada.

\n\n

¿Qué es una unidad de software? Pues normalmente se trata de una función o bien de una clase en OOP a través del ejercicio de sus métodos públicos que son los que definen su comportamiento observable.

\n\n

Sin embargo, muchas clases usarán otras como colaboradoras y esto introduce problemas: ¿qué parte del comportamiento observable de una clase corresponde a su propio código y qué parte corresponde al de sus colaboradores?

\n\n

Para discriminar esto tenemos que mantener bajo control el comportamiento de esos colaboradores.

\n\n

Es muy similar a cuando hacemos un experimento científico: para poder afirmar que cierto cambio se produce como consecuencia de un factor que estamos estudiando tenemos que controlar las demás variables que podrían estar afectando.

\n\n

En algunos casos podríamos eliminarlas. Por ejemplo, hacer un experimento en una cámara de vacío para evitar el efecto de rozamiento del aire.

\n\n

En otros casos no podemos hacer eso y tenemos que recurrir a otras técnicas, como puede ser aleatorizarlas, lo que nos dará un margen de error previsible en la medida del cambio que estamos observando, o controlarlas: saber exactamente en qué condiciones hacemos el experimento, al respecto de esas variables y repetirlo bajo distintos conjuntos de condiciones.

\n\n

Pues bien, en el tema de los tests doubles la estrategia va por ahí. El objetivo es que los tengan un efecto nulo sobre el comportamiento de nuestra unidad bajo test o que podamos tenerlo controlado.

\n\n

Por qué y para qué de los tests doubles

\n\n

Utilizamos test doubles para evitar efectos no deseados en nuestros tests y asegurarnos que el comportamiento que estamos probando corresponde a la unidad de software:

\n\n

Controlar el comportamiento de un colaborador o dependencia y poder generar diversos escenarios en los que probar nuestra unidad de software.
Que el test no se vea afectado por la disponibilidad o no de ciertos recursos. Por ejemplo, podemos suplantar un servicio externo con un doble que nos devuelva respuestas determinadas, e incluso simular que no está disponible para asegurarnos de que nuestro código sabe reaccionar a esa situación.
Que los tests se ejecuten con mayor rapidez al simular componentes del sistema que, de otro modo, podrían tener bajo rendimiento, consumir muchos recursos, etc, como puede ser una base de datos, etc.
Evitar trabajar con datos reales o de producción.

\n\n

Test doubles y dónde encontrarlos

\n\n

Hay varios tipos de test doubles aunque tendemos a llamarlos a todos mocks. Pero, siendo estrictos, los mocks son un tipo específico de test double.

\n\n

The little mocker

\n\n

Los vamos a agrupar en función de si acoplan, o no, el test a la implementación. Esto es: hay test doubles que esperan ser usados con un cierto patrón, lo cual se refleja en el test. Si ese patrón de uso cambia, el test fallará. Por eso decimos que provocan un acoplamiento del test a la implementación del SUT (subject under test) y eso hace que el test se vuelva frágil. Sobre esto volveremos más adelante.

\n\n

Test doubles que no acoplan el test a la implementación

\n\n

Dummies y Stubs no tienen expectativas sobre su uso y se limitan a participar en el comportamiento del SUT.

\n\n

Dummy

\n\n

Los dummies son dobles que creamos porque nos interesa su interfaz, no su comportamiento. Obviamente, nuestro SUT los llama pero no espera ninguna respuesta o su comportamiento no depende de ella. Por tanto, el dummy no debe implementar comportamiento. En pocas palabras, un dummy:

\n\n

Implementa una interfaz

\n\n

El caso típico es poder instanciar nuestro objeto bajo test cuando necesita inyección de colaboradores en construcción.

\n\n

 1 namespace Tests\\Dojo\\Doubles;\n 2 \n 3 use Dojo\\Doubles\\SomeService;\n 4 use PHPUnit\\Framework\\TestCase;\n 5 \n 6 class DummyLogger implements LoggerInterface\n 7 {\n 8     //....\n 9 }\n10 \n11 class SomeServiceTest extends TestCase\n12 {\n13     public function testSomeServiceCanBeInstantiated()\n14     {\n15         $logger = new DummyLooger();\n16         $someService = new SomeService($logger);\n17         $this->assertInstanceOf(SomeService::class, $someService);\n18     }\n19 }\n

\n\n\n\n

En el ejemplo anterior, nuestro SUT (SomeService) utiliza un Logger, pero nosotros no vamos a mirar qué ha registrado.

\n\n

Stub

\n\n

En la mayor parte de los casos, un test double “dummy” no es suficiente: normalmente querremos que los colaboradores proporcionen respuestas a nuestro SUT. Por ejemplo, podríamos necesitar un servicio al que consultar la fecha y hora actuales, tal vez otro que nos diga si un usuario es válido o cualquier ejemplo que se te ocurra.

\n\n

Para eso necesitamos otro tipo de test double que se denomina stub. Un stub es un objeto que:

\n\n

Implementa una interfaz
Tiene un comportamiento programado: al llamar a uno de sus métodos devuelve una respuesta conocida

\n\n

A continuación podemos ver un ejemplo de Stub. La clase ClockServiceStub nos dará siempre la misma hora que le hayamos programado al instanciar un objeto de la misma. De este modo, siempre sabremos qué fecha u hora nos va a devolver, cosa que no ocurre con la clase real.

\n\n

 1 use DateTimeImmutable;\n 2 \n 3 interface ClockServiceInterface\n 4 {\n 5     public function getCurrentDateTime() : DateTimeImmutable;\n 6 }\n 7 \n 8 class ClockServiceStub implements ClockServiceInterface\n 9 {\n10     /**\n11      * @var DateTimeImmutable\n12      */\n13     private $date;\n14 \n15     public function __construct(string $dateString)\n16     {\n17         $this->date = new DateTimeImmutable($dateString);\n18     }\n19 \n20     public function getCurrentDateTime() : DateTimeImmutable\n21     {\n22         return $this->date;\n23     }\n24 }\n25 \n26 $dateForTesting = new ClockServiceStub('2018-03-12');\n

\n\n\n\n

Test doubles acoplados

\n\n

Mocks y Spies mantienen expectativas sobre cómo son usados por el SUT, lo que quiere decir que hacen aserciones sobre si son llamados de una manera específica.

\n\n

El problema es que en caso de que cambie la implementación del SUT, el resultado del test podría cambiar aunque el comportamiento se mantenga, por el hecho de que no se cumplen las expectativas sobre el uso de los colaboradores.

\n\n

Pongamos un ejemplo sencillo. Supongamos que el método bajo test hace dos llamadas a un Servicio que envía emails porque queremos notificar a dos destinatarios una determinada situación, así que hacemos un Double del servicio de Email que será llamado dos veces. Por tanto, el test espera dos llamadas y pasará siempre y cuando la implementación realice ambas llamadas.

\n\n

Pero ahora, imaginemos que nuestro Servicio de email puede enviar a una lista de direcciones con una sola llamada. Si cambiamos la implementación para hacerlo así, nuestro test fallará, puesto que espera dos llamadas y sólo se realiza una. Sin embargo, el comportamiento del SUT sigue siendo correcto porque se envían dos emails.

\n\n

Entonces, si el comportamiento es correcto, ¿por qué falla el test? Pues porque estos test doubles pueden generar un acoplamiento del test a la implementación del SUT a través de las expectativas que les programamos.

\n\n

Spy

\n\n

Un Spy es un Stub que, además, guarda la información sobre cómo ha sido llamado, de modo que podemos hacer aserciones acerca de esa información. Esto implica que el test se acopla a la implementación del SUT, introduciendo un factor de fragilidad que hay que tener en cuenta.

\n\n

En resumen, un Spy:

\n\n

Implementa una interfaz
Tiene un comportamiento programado
Nos permite verificar en el test si ha sido usado de cierta manera
Introduce fragilidad en el test

\n\n

Lo que sigue es un ejemplo muy esquemático de lo que sería un Spy de una hipotética clase Mailer. El Spy se limita a contar las veces que se llama al método send, lo que nos permite hacer aserciones en un test.

\n\n

 1 interface Mailer\n 2 {\n 3     public function send(Message $message) : void;\n 4 }\n 5 \n 6 class MailerSpy implements Mailer\n 7 {\n 8     private $calls = 0;\n 9 \n10     public function send(Message $message) : void\n11     {\n12         $this->calls++;\n13     }\n14 \n15     public function getCalls()\n16     {\n17         return $this->calls;\n18     }\n19 }\n20 \n21 class ServiceTest extends TestCase\n22 {\n23     public function testMailer()\n24     {\n25         $mailerSpy = new MailerSpy();\n26         $sut = new Service($mailerSpy);\n27         $sut->execute();\n28         $this->assertEquals(2, $mailerSpy->getCalls());\n29     }\n30 }\n

\n\n\n\n

Mock

\n\n

El Mock es un Spy que espera ser usado por el SUT de una manera específica, como por ejemplo que se llame a un método con ciertos argumentos. Si esta expectativa no se cumple el test no pasa.

\n\n

Al igual que un Stub, tiene una respuesta programada, o incluso varias. La diferencia es que al hacer que esperen una forma de uso concreta se genera una aserción implícita que reside en el Mock, no en el test.

\n\n

En resumen, un mock:

\n\n

Implementa una interfaz
Tiene un comportamiento programado
Espera ser usado de una cierta manera
Introduce fragilidad en el test

\n\n

Los Mocks necesitan de una programación más compleja que los Spies, por lo que veremos en próximos artículos cómo generarlos. De momento, aquí tenemos un ejemplo usando Prophecy

\n\n

 1 class ServiceTest extends TestCase\n 2 {\n 3     public function testMailer()\n 4     {\n 5         $mailerProphecy = $this->prophesize(Mailer::class);\n 6         $mailerProphecy->send(Argument::type(Message::class))\n 7             ->shouldBeCalled();\n 8         $sut = new Service($mailerProphecy->reveal());\n 9         $sut->execute();\n10     }\n11 }\n

\n\n\n\n

\nTest doubles que son implementaciones alternativas

\n\n

Fake

\n\n

Un Fake es una implementación de la interfaz de una clase que se crea específicamente para ser utilizada en situaciones de test. Como tal tiene comportamiento de negocio y, en realidad, necesita sus propios tests para asegurarnos de que este es correcto.

\n\n

Las razones para crear Fakes son varias. Quizá la principal pueda ser la de realizar pruebas de integración sin las limitaciones de las implementaciones de producción, como puede ser el acceso a bases de datos y otros recursos remotos, que son lentos y pueden fallar, por ejemplo un repositorio implementado en memoria.

\n\n

Alternativas para generar test doubles

\n\n

Usar las clases reales

\n\n

Hay muchas ocasiones en las que no tiene sentido utilizar test doubles. En su lugar utilizaremos las clases reales en los tests:

\n\n

\nValue Objects: los VO, por definición, no pueden tener side effects ni dependencias, así que al utilizarlos en los tests podemos tener la seguridad de que su efecto sobre el SUT es el esperado.
\nDTO: no dejan de se objetos sin comportamiento, por lo que podemos usarlos sin problema.
\nRequests, Commands, Events: los objetos que son mensajes y no contienen lógica no necesitan ser doblados.
Cualquier otra clase que que no tenga side effects ni dependencias.

\n\n

Implementación directa

\n\n

Fundamentalmente se trata de crear objetos implementando la interfaz deseada y con un comportamiento nulo o limitado a lo que necesitemos para usarlo como test double en cualquiera de sus tipos.

\n\n

Si esta implementación incluye lógica de negocio estaríamos hablando de un Fake.

\n\n

Self-shunt

\n\n

El self-shunt es una técnica bastante curiosa que consiste en que el propio TestCase sea el test double haciendo que implemente la interfaz que necesitamos reproducir, lo que nos permite recoger información al estilo de un Spy.

\n\n

Obviamente no es una técnica para usar de forma habitual, pero puede ser práctica en los primeros estadios de desarrollo, cuando no hemos creado todavía el colaborador y queremos ir haciéndonos una idea de su interfaz, o cuando ésta es muy simple y tiene sólo uno ó dos métodos.

\n\n

He aquí la versión self-shunt del MailerSpy.

\n\n

 1 class ServiceTest extends TestCase implements Mailer\n 2 {\n 3     private $mailerCalls = 0;\n 4 \n 5     public function testMailer()\n 6     {\n 7         $sut = new Service($this);\n 8         $sut->execute();\n 9         $this->assertEquals(2, $this->getCalls());\n10     }\n11 \n12     public function send(Message $message) : void\n13     {\n14         $this->mailerCalls++;\n15     }\n16 }\n

\n\n\n\n

A la larga, los self-shunts los iremos eliminando a medida que desarrollamos y que, consecuentemente, vamos refactorizando los tests.

\n\n

Michael Feathers describe el self-shunt en este artículo.\nTambién es interesante echar un vistazo a este artículo que compara los tres métodos básicos de mocking, escrito por Paul Pagel.

\n\n

Clases anónimas

\n\n

Desde PHP 7 podemos utilizar clases anónimas. Esto es útil en los tests cuando necesitamos objetos sencillos que no se van a reutilizar fuera de ese test.

\n\n

He aquí el anterior ejemplo de Mailer con esta técnica:

\n\n

 1 class ServiceTest extends TestCase\n 2 {\n 3     public function testMailer()\n 4     {\n 5         $mailer = new class implements Mailer {\n 6 \n 7             private $calls = 0;\n 8 \n 9             public function send(Message $message) : void\n10             {\n11                 $this->calls++;\n12             }\n13 \n14             public function getCalls()\n15             {\n16                 return $this->calls;\n17             }\n18         };\n19 \n20         $sut = new Service($mailer);\n21         $sut->execute();\n22         $this->assertEquals(2, $mailer->getCalls());\n23     }\n24 }\n

\n\n\n\n

Terminando

\n\n

En este artículo hemos hecho un repaso de los tipos de test doubles. En próximas entregas veremos cómo usarlos en tests.

\n\n\n

Test doubles (2) Principios de diseño

\n\n

Los principios de diseño están muy relacionados con el testing de tal forma que son tanto objetivo de diseño como herramienta para lograrlo.

\n\n

En el capítulo anterior sobre test doubles, hicimos un repaso de los mismos y sus tipos. En este, reflexionaremos sobre la aplicación de principios de diseño y el uso de test-doubles.

\n\n

Las consecuencias sobre la escritura de tests se podrían sintetizar en dos beneficios principales:

\n\n

El código que sigue principios de diseño es más fácil de testear.
La creación de test doubles se simplifica si las clases que se doblan siguen los principios de diseño.

\n\n

Por otro lado, los buenos test tienden a llevarnos a mejores diseños, precisamente porque los mejores diseños nos facilitan la escritura de buenos tests. Es un círculo virtuoso.

\n\n

En otras palabras: cuando es difícil poner bajo test un código es que tiene problemas de diseño.

\n\n

Principios de diseño y doubles

\n\n

Esta relación entre principio de diseño y test doubles se manifiesta de muchas maneras.

\n\n

Como hemos visto, si el código bajo test sigue principios de diseño, será más fácil escribir los tests y, por el contrario, si vemos que montar la prueba resulta complicado nos está indicando que deberíamos cambiar el diseño del código bajo test.

\n\n

Incluso si vemos que generar el test double es complicado, eso nos estaría indicando tanto que la clase colaboradora tiene también problemas o que la interacción entre unidad bajo test y colaborador no está bien planteada.

\n\n

Única responsabilidad

\n\n

Una clase que sólo tiene una razón para cambiar será más fácil de testear que una clase que tiene múltiples responsabilidades.

\n\n

Al desarrollar los test doubles, este principio nos beneficia en el sentido de que las clases dobladas serán más sencillas de definir al tener que reproducir un sólo tipo de comportamiento.

\n\n

Abierto para extensión, cerrado para modificación

\n\n

El principio abierto/cerrado se refiere a que las clases estarán abiertas para que su comportamiento pueda ser modificado extendiéndolas sin cambiar su código.

\n\n

Cuando creamos un test double lo que queremos conseguir es un objeto equivalente al real, pero con un comportamiento distinto. Por ello, en muchos casos extendemos por herencia la clase original para crear el test double o, mejor, implementamos su interfaz.

\n\n

El principio entonces se aplica en el sentido de que un objeto o una clase no debería modificarse ya sea para testearla, ya sea para poder utilizarla como doble en un test.

\n\n

Sustitución de Liskov

\n\n

El principio de sustitución de Liskov está en la base de nuestra posibilidad de realizar test doubles.

\n\n

Este principio dice que en una jerarquía de clases, las clases base y las derivadas deben ser intercambiables, sin tener que cambiar el código que las usa.

\n\n

Cuando creamos test doubles extendemos clases o bien implementamos interfaces. El hecho de que se cumpla este principio es lo que permite que podamos introducir doubles sin tener que tocar el código de la clase bajo test.

\n\n

Los test doubles, por tanto, deben cumplir este principio en lo que se refiere a la interfaz que interesa a nuestra unidad bajo test.

\n\n

Segregación de interfaces

\n\n

El principio de segregación de interfaces nos dice que una clase no debe depender de funcionalidad que no necesita. En otras palabras: las interfaces deben exponer sólo los métodos necesarios. Si fuese necesario, una clase implementará varias interfaces.

\n\n

Cuanto mejor aplicado esté este principio más fácil será crear doubles y los tests serán menos complejos y más precisos ya que no tendremos que simular un montón de comportamientos.

\n\n

Si una clase colaboradora tuviese veinte métodos, al crear su double necesitaríamos implementar los veinte, aunque estemos interesados tan sólo en dos. En ese caso, es preferible extraer esos dos métodos a una interfaz, a partir de la cual crear el double. Y eso nos podría llevar, como beneficio extra, a la posibilidad de extraer funcionalidad de la clase, repartiendo mejor las responsabilidades.

\n\n

Inversión de dependencias

\n\n

La inversión de dependencias nos dice que siempre debemos depender de abstracciones. De este modo cambiar la implementación que usamos se convierte en algo tan trivial como inyectar una diferente.

\n\n

Si dependemos de una abstracción, y no hay nada más abstracto que una interfaz, es fácil generar implementaciones específicas para situaciones de test.

\n\n

Ley de Demeter o del mínimo conocimiento

\n\n

La ley de Demeter nos dice que los objetos no deben tener conocimiento de cómo funcionan otros objetos internamente.

\n\n

Si un objeto A usa otro objeto B que, a su vez, utiliza internamente un tercer objeto C para responder a esa petición, entonces A no debe conocer nada de C.

\n\n

En el caso de los test esto significa que por muchas dependencias que pueda tener una clase doblada, no las necesitamos para crear el double ya que sólo nos interesa su interfaz o su comportamiento, no su estructura. Y si las necesitásemos entonces es que tenemos un problema con el diseño.

\n\n

DRY: Evita las repeticiones

\n\n

Cualquier repetición en el código debería llevarnos a un refactor con el objetivo de reducirla o eliminarla.

\n\n

Este principio no se aplica sólo al código probado, sino también a los propios tests y, por supuesto, a los test doubles.

\n\n

El principio DRY no tiene que buscarse necesariamente por diseño previo, sino que podemos aplicarlo a medida que detectamos repeticiones en nuestro código. Por ejemplo, si observamos que estamos usando el mismo test-double por tercera vez, puede ser el momento de moverlo a una propiedad del Test Case e inicializarlo en el setUp.

\n\n

YAGNI: No lo vas a necesitar

\n\n

El principio Yagni nos recuerda que no deberíamos desarrollar aquello que no necesitamos ahora.

\n\n

Por lo tanto, nuestros tests doubles tienen que responder a la necesidad específica que tengamos en el momento de crearlo. Un test double puede comenzar siendo un simple dummy en un test para pasar a ser un Mock en otro.

\n\n

Un ejemplo

\n\n

A continuación veremos un pequeño ejemplo de código de test en el que se pueden observar varios principios de diseño en funcionamiento.

\n\n

Suponemos un servicio SendNotificationService que utiliza un Mailer para enviar mensajes.

\n\n

Veamos un par de posibles tests:

\n\n

 1 use Dojo\\MailerExample\\Application\\SendNotificationService;\n 2 \n 3 use PHPUnit\\Framework\\TestCase;\n 4 \n 5 interface Mailer\n 6 {\n 7     public function send(Message $message): bool;\n 8 }\n 9 \n10 class SuccessfulMailerStub implements Mailer\n11 {\n12     public function send(Message $message): bool\n13     {\n14         return true;\n15     }\n16 }\n17 \n18 class FailedMailerStub implements Mailer\n19 {\n20     public function send(Message $message): bool\n21     {\n22         throw new MailServiceDownException();\n23     }\n24 }\n25 \n26 interface Message\n27 {\n28     public function subject(): string;\n29     public function body(): string;\n30 }\n31 \n32 class MessageStub implements Message\n33 {\n34     public function subject(): string\n35     {\n36         return 'Subject';\n37     }\n38     public function body(): string\n39     {\n40         return 'Body';\n41     }\n42 }\n43 \n44 class SendNotificationServiceTest extends TestCase\n45 {\n46     public function testSendNotificationCanSendAMessage() : void\n47     {\n48         $message = new MessageStub();\n49         $mailer = new SuccessfulMailerStub();\n50         \n51         $sendNotification = new SendNotificationService($mailer);\n52         $this->assertTrue($sendNotification->send($message));\n53     }\n54 \n55     public function testSendNotificationCanNotSendMessage() : void\n56     {\n57         $this->expectException(NotificationCouldNotBeSent::class);\n58         \n59         $message = new MessageStub();\n60         $mailer = new FailedMailerStub();\n61         \n62         $sendNotification = new SendNotificationService($mailer);\n63         $sendNotification->send($message);\n64     }\n65 }\n

\n\n\n\n

Tanto Mailer como Message son interfaces, de modo que el servicio no depende de ninguna implementación concreta. En el proyecto podríamos estar usando SwiftMailer, por poner un ejemplo, pero nada nos impediría utilizar una implementación que ponga mensaje en Twitter, Slack, Telegram…, con tal de escribir un Adapter que cumpla la interfaz de Mailer.

\n\n

En el test la implementación concreta nos da igual. Nosotros sólo queremos que nuestro servicio intente enviar el mensaje y devuelva una excepción si no puede hacerlo.

\n\n

Al aplicar la Inversión de Dependencias, es decir, al depender de interfaces, podemos preparar Stubs que reproduzcan el comportamiento que necesitamos sin mucho esuerzo. En nuestro caso, que el mensaje se ha enviado correctamente (el Mailer devolvería true).

\n\n

Por otra parte, está claro que Mailer sólo tiene una responsabilidad, que es enviar mensajes, por lo que su comportamiento es sencillo de simular. Y también debería verse que se cumplen los principios Abierto/Cerrado y Liskov. El hecho de que sólo nos interese un método en la interfaz de Mailer, nos dice que también aplicamos Segregación de Interfaces: nuestras implementaciones concretas podrían tener otros métodos, pero para esta situación sólo queremos uno.

\n\n

Message aquí actúa como dummy, no queremos que haga nada en particular, pero lo necesitamos para cumplir la interface.

\n\n

He dejado las variables para que el test sea más fácil de leer, pero podrían eliminarse haciendo un inline variable dado que no tenemos que hacer nada con ellas. Los test así quedarían:

\n\n

 1 class SendNotificationServiceTest extends TestCase\n 2 {\n 3     public function testSendNotificationCanSendAMessage() : void\n 4     {\n 5         $sendNotification = new SendNotificationService(new SuccessfulMailerStub());\n 6         $this->assertTrue($sendNotification->send(new MessageStub()));\n 7     }\n 8 \n 9     public function testSendNotificationCanNotSendMessage() : void\n10     {\n11         $this->expectException(NotficationCouldNotBeSent::class);\n12         $sendNotification = new SendNotificationService(new FailedMailerStub());\n13         $sendNotification->send(new MessageStub());\n14     }\n15 }\n

\n\n\n\n

Este pequeño refactor que acabamos de hacer contribuye a ejemplificar DRY dentro de lo limitado del ejemplo. Otra opción sería, sacar $message a una propiedad del TestCase para poder reusarlo:

\n\n

 1 class SendNotificationServiceTest extends TestCase\n 2 {\n 3     private $message;\n 4 \n 5     public function setUp() : void\n 6     {\n 7         $this->message = new MessageStub();\n 8     }\n 9 \n10     public function testSendNotificationCanSendAMessage() : void\n11     {\n12         $mailer = new SuccessfulMailerStub();\n13         \n14         $sendNotification = new SendNotificationService($mailer);\n15         $this->assertTrue($sendNotification->send($this->message));\n16     }\n17 \n18     public function testSendNotificationCanNotSendMessage() : void\n19     {\n20         $this->expectException(NotiicationCouldNotBeSent::class);\n21         $mailer = new FailedMailerStub();\n22         \n23         $sendNotification = new SendNotificationService($mailer);\n24         $sendNotification->send($this->message);\n25     }\n26 }\n

\n\n\n\n

En resumidas cuentas, unos principios nos ayudan a cumplir otros.

\n\n

En particular, al invertir las dependencias y depender sólo de una interfaz sencilla, nuestra clase bajo test no puede atarse a una implementación concreta, lo que facilita cumplir la Ley de Demeter, pues puede que en este momento de desarrollo ni siquiera hayamos decidido cuál va a ser el mecanismo de distribución de esas notificaciones.

\n\n

Lo mismo ocurre respecto al principio YAGNI. Nuestro servicio no tiene que estar preparado para implementaciones que podrían usarse en un futuro, sólo tiene que saber usar un Mailer. Aunque inicialmente estuviésemos pensando en usar el correo electrónico, dentro de un tiempo podríamos lanzarlas por Slack.

\n\n

En resumen

\n\n

Los principio de diseño no rigen sólo para el código de producción, sino que deberían impregnar todo el desarrollo, incluyendo los test y los test doubles cuando los necesitemos.

\n\n\n

Resolver problemas con baby-steps

\n\n

Una de las características de trabajar con metodología TDD es que nos forzamos a avanzar en pasos muy pequeños hacia la solución del problema. Estos pequeños pasos se conocen como baby-steps. De hecho, es una de la cosas que distinguen TDD de otras formas de escribir tests antes que el código.

\n\n

A muchas personas que comienzan a utilizar TDD les preocupa la dimensión de estos pasos. Dicho de otra forma: ¿cómo de pequeños deberían ser?

\n\n

No hay una respuesta definitiva. Kent Beck, en su libro Test Driven Development by Example explica que los baby-steps se han de ir adaptando a la experiencia y a la dificultad del problema: En resumen:

\n\n

Con la experiencia en TDD aprendemos a juzgar qué tamaño de paso nos viene bien y la seguridad adquirida nos permite avanzar en saltos más largos.
Pero cuando un problema resulta complicado, una buena solución es tratar de avanzar en pasos más pequeños.

\n\n

En este capítulo vamos a presentar un caso en el que el problema parece apuntar a una solución “todo de una vez” en un solo paso, cuando en realidad podemos avanzar con más seguridad con pasos más cortos.

\n\n

Un problema sencillo, pero con intríngulis\n

\n\n

El problema concreto era desarrollar un pequeño servicio capaz de clasificar documentos. Recibe el path de un archivo y unos metadatos y, a partir de esa información, decide dónde debe guardarse el documento, devolviendo una ruta al lugar en donde se almacenará de forma definitiva.

\n\n

La verdad es que parece más difícil de lo que es. Como veremos, el servicio simplemente entrega un string compuesto a partir de elementos extraídos de la información aportada. Inmediatamente nos damos cuenta de que tan solo hay que obtener los fragmentos necesarios, concatenarlos y devolver el resultado.

\n\n

Supongamos un centro de enseñanza en el que queremos desarrollar una aplicación que permita al alumnado enviar documentos subiéndolos en una web preparada al efecto. La cuestión es que esos documentos se guarden automáticamente en un sistema de archivos con una estructura determinada. Aunque este sistema podría servir para muchas tareas, voy a simplificar el problema a un único caso:

\n\n

Los documentos relacionados con trabajos escolares se guardan en una ubicación específica por curso escolar, etapa, nivel educativo, tutoría, asignatura y alumno.
Además, el nombre de archivo se cambiará para refleje un identificador de la tarea y una marca de tiempo.

\n\n

Es decir, que si un alumno con número de matrícula 5433, matriculado en 5º C de Primaria sube el próximo lunes (12-03-2018) el archivo deberes-de-mates.pdf, éste deberá situarse en la ruta:

\n\n

1 2017-2018/primaria/5/5C/matematicas/5433/2018-03-12-deberes.pdf\n

\n\n\n\n

Aunque no forma parte de la tarea concreta que vamos a realizar, se supone que la información necesaria se obtiene a través del formulario de la web, de la identificación del usuario conectado, de datos almacenados en el repositorio de alumnos, y otros se obtienen en el momento.

\n\n

Así, por ejemplo, el número de matrícula (que sería el ID del alumno) se obtiene de su login. Este dato nos permite obtener la entidad Student del repositorio correspondiente, a la cual podemos interrogar sobre su curso, tutoría y etapa.

\n\n

Por supuesto, la fecha se obtiene del sistema y, con ella, es posible elaborar el fragmento de curso escolar.

\n\n

La solución es bastante obvia, pero no adelantemos acontecimientos…

\n\n

Un problema de TDD

\n\n

La pregunta es: ¿cómo resolvemos este desarrollo utilizando TDD y que los tests sean útiles?

\n\n

Me explico.

\n\n

La interfaz de este tipo de servicios contiene un único método que devuelve el string que necesitamos.

\n\n

En una metodología de tests a posteriori podríamos simplemente testear el happy path y santas pascuas, aparte de algunas situaciones problemáticas como que no se encuentre el estudiante con ese ID o similares, en las que podríamos testear que se lance excepción.

\n\n

Incluso con una metodología test antes que el código podríamos plantear lo mismo, y pensar que estamos haciendo TDD.

\n\n

Y eso no sería TDD, o al menos no sería una forma muy útil de TDD.

\n\n

Veámoslo en forma de código, el cual voy a simplificar evitando usar objetos de dominio para centrarme en el meollo de este caso.

\n\n

Para llamar al servicio usaremos este objeto ClassifyDocumentRequest, con el que pasamos la información obtenida en el controlador al servicio:

\n\n

 1 namespace Dojo\\ClassifyDocument\\Application;\n 2 \n 3 \n 4 use DateTime;\n 5 \n 6 class ClassifyDocumentRequest\n 7 {\n 8     /**\n 9      * @var string\n10      */\n11     private $studentId;\n12     /**\n13      * @var string\n14      */\n15     private $subject;\n16     /**\n17      * @var string\n18      */\n19     private $path;\n20     /**\n21      * @var DateTime\n22      */\n23     private $dateTime;\n24     /**\n25      * @var string\n26      */\n27     private $type;\n28 \n29     public function __construct(\n30         string $studentId,\n31         string $subject,\n32         string $type,\n33         string $path,\n34         DateTime $dateTime\n35     ) {\n36         $this->studentId = $studentId;\n37         $this->subject = $subject;\n38         $this->type = $type;\n39         $this->path = $path;\n40         $this->dateTime = $dateTime;\n41     }\n42 \n43     /**\n44      * @return string\n45      */\n46     public function studentId() : string\n47     {\n48         return $this->studentId;\n49     }\n50 \n51     /**\n52      * @return string\n53      */\n54     public function subject() : string\n55     {\n56         return $this->subject;\n57     }\n58 \n59     /**\n60      * @return string\n61      */\n62     public function type() : string\n63     {\n64         return $this->type;\n65     }\n66 \n67     /**\n68      * @return string\n69      */\n70     public function path() : string\n71     {\n72         return $this->path;\n73     }\n74 \n75     /**\n76      * @return DateTime\n77      */\n78     public function dateTime() : DateTime\n79     {\n80         return $this->dateTime;\n81     }\n82 }\n

\n\n\n\n

El servicio se utilizaría más o menos así:

\n\n

1 $classifyDocumentRequest = new ClassifyDocumentRequest(\n2 \t'5433',\n3 \t'Matemáticas',\n4 \t'deberes'\n5 \t'misejercicioschupiguais.pdf',\n6 \tnew DateTime('2018-03-12')\n7 );\n8 \n9 $route = $this->classifyDocument->execute($classifyDocumentRequest);\n

\n\n\n\n

Al ejecutarlo, debería devolvernos una cadena de este estilo:

\n\n

1 2017-2018/primaria/5/5C/matematicas/5433/2018-03-12-deberes.pdf\n

\n\n\n\n

El enfoque de tests antes que el código pero que no es TDD

\n\n

Veamos: ¿cuál sería un primer test para este problema?. La solución rápida sería algo más o menos como esto:

\n\n

 1 namespace Tests\\Dojo\\ClassifyDocument\\Application;\n 2 \n 3 use DateTime;\n 4 use Dojo\\ClassifyDocument\\Application\\ClassifyDocument;\n 5 use Dojo\\ClassifyDocument\\Application\\ClassifyDocumentRequest;\n 6 use PHPUnit\\Framework\\TestCase;\n 7 \n 8 class ClassifyDocumentTest extends TestCase\n 9 {\n10     public function testVAlidRequestShouldGenerateRoute()\n11     {\n12         $classifyDocumentRequest = new ClassifyDocumentRequest(\n13             '5433',\n14             'Matemáticas',\n15             'deberes',\n16             'misejercicioschupiguais.pdf',\n17             new DateTime('2018-03-12')\n18         );\n19         $classifyDocumentService = new ClassifyDocument();\n20         $route = $classifyDocumentService->execute($classifyDocumentRequest);\n21         $expected = '2017-2018/primaria/5/5C/matematicas/5433/2018-03-12-deberes.pdf\\\n22 ';\n23         $this->assertEquals($expected, $route);\n24     }\n25 }\n

\n\n\n\n

\n
– No sé, Rick… Parece bueno.
\n– ¡Pues no lo es!
\n

\n\n

Veamos. Este test tiene algunos problemas aunque aparentemente es correcto. El principal de ellos es que nos obliga a implementar toda la funcionalidad de una sola tacada y resulta que tenemos que extraer ni más ni menos que nueve fragmentos de información para componer la ruta a partir de cinco datos: ¿no nos convendría ir por partes?

\n\n

¿Qué pasa si en el futuro un cambio provoca que el test no pase? Pues que no tenemos forma de saber a través del test qué parte concreta está fallando. Este caso es bastante simple, pero imagínatelo en desarrollos con algoritmos más complejos.

\n\n

Podríamos considerar éste como un test de aceptación: dada una petición válida, devuelve una ruta válida. Así que no vamos a tirar este test, sino que lo utilizaremos como lo que es: un test de aceptación que nos diga si hemos terminado de desarrollar la funcionalidad. Así que, mientras tanto, lo pongo en un archivo aparte y ya volveré a él más adelante.

\n\n

Como test unitario, en un enfoque TDD, este test no nos sirve de mucho pues no nos dice por dónde empezar o qué hacer a continuación. Cada fragmento de la ruta tiene su propia lógica en tanto que se obtiene de una manera diferente y ocupa una posición específica.

\n\n

¿Y cómo lo reflejamos en el proceso de TDD?

\n\n

El enfoque TDD

\n\n

En otro capítulo del libro mostramos una versión de la Luhn Code Kata, que nos viene muy bien precisamente para practicar cómo abordar estos problemas. Se trata de analizar la situación para entender cómo podemos dividir el problema en partes manejables, testeando cada una por separado.

\n\n

TDD del curso escolar

\n\n

El primer elemento que tenemos que generar es el curso escolar, el cual es una cadena formada por el año natural en que comienza y el año en que termina, separados por un guión. Por ejemplo:

\n\n

1 2017-2018\n

\n\n\n\n

Calcularlo es relativamente sencillo: dada una fecha, si el mes es mayor o igual que septiembre, el curso escolar comienza ese año. Si el mes es menor que septiembre el curso escolar ha comenzado el año anterior.

\n\n

Así que empiezo creando un test que falle:

\n\n

 1 namespace Tests\\Dojo\\ClassifyDocument;\n 2 \n 3 use DateTime;\n 4 use Dojo\\ClassifyDocument\\ClassifyDocument;\n 5 use Dojo\\ClassifyDocument\\ClassifyDocumentRequest;\n 6 use PHPUnit\\Framework\\TestCase;\n 7 \n 8 class ClassifyDocumentTest extends TestCase\n 9 {\n10 \n11     public function testSchoolYearIsTheFirstElementOfTheRoute()\n12     {\n13         $classifyDocumentRequest = new ClassifyDocumentRequest(\n14             '5433',\n15             'Matemáticas',\n16             'deberes',\n17             'misejercicioschupiguais.pdf',\n18             new DateTime('2018-03-12')\n19         );\n20         $classifyDocumentService = new ClassifyDocument();\n21         $route = $classifyDocumentService->execute($classifyDocumentRequest);\n22         $this->assertEquals('2017-2018', $route);\n23     }\n24 }\n

\n\n\n\n

Este test fallará, en primer lugar porque no se encuentra la clase ClassifyDocument que aún no hemos creado. Sin embargo y de momento, me interesa resaltar cómo voy a probar la generación de cada fragmento.

\n\n

Para empezar a trabajar, mi ruta sólo va a tener un elemento, por lo que no me preocupo de otra cosa que generarlo.

\n\n

Para ello, voy resolviendo las cosas que me pide el resultado de pasar cada test. En primer lugar, crear la clase y, luego, el método.

\n\n

 1 namespace Dojo\\ClassifyDocument;\n 2 \n 3 \n 4 class ClassifyDocument\n 5 {\n 6 \n 7     /**\n 8      * ClassifyDocument constructor.\n 9      */\n10     public function __construct()\n11     {\n12     }\n13 \n14     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n15 ng\n16     {\n17     }\n18 }\n

\n\n\n\n

Y, después, una implementación obvia para hacer que el test pase:

\n\n

 1 namespace Dojo\\ClassifyDocument;\n 2 \n 3 \n 4 class ClassifyDocument\n 5 {\n 6 \n 7     /**\n 8      * ClassifyDocument constructor.\n 9      */\n10     public function __construct()\n11     {\n12     }\n13 \n14     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n15 ng\n16     {\n17     \treturn '2017-2018';\n18     }\n19 }\n

\n\n\n\n

Bien. Nuestro siguiente paso será probar que generamos la ruta correcta para la fecha de subida del archivo y obligarnos a implementar algo para ello. Así que introducimos un cambio de fechas, de modo que podamos tener un nuevo test que falle. Ese test será el siguiente:

\n\n

 1     public function testSchoolYearIsTheFirstElementOfTheRouteFirstQuarteIsTheSameYea\\\n 2 r()\n 3     {\n 4         $classifyDocumentRequest = new ClassifyDocumentRequest(\n 5             '5433',\n 6             'Matemáticas',\n 7             'deberes',\n 8             'misejercicioschupiguais.pdf',\n 9             new DateTime('2018-10-12')\n10         );\n11         $classifyDocumentService = new ClassifyDocument();\n12         $route = $classifyDocumentService->execute($classifyDocumentRequest);\n13         $this->assertEquals('2018-2019', $route);\n14     }\n

\n\n\n\n

En este test he cambiado la fecha de entrega para el último trimestre del año, de modo que el curso escolar sea 2018-2019. Obviamente falla porque nuestra primera implementación es inflexible.

\n\n

Sin embargo, el cálculo del curso escolar no es una responsabilidad que incumba a nuestra clase, ya que se ocupa únicamente de generar rutas. Lo ideal sería tener un servicio al que dándole una fecha nos devuelva el curso escolar. Esta funcionalidad la necesitaremos seguramente en un montón de sitios, así que vamos a suponer que lo tenemos aunque no esté todavía implementado, por lo que introduciremos un stub que nos haga el trabajo.

\n\n

Primero creamos una interfaz:

\n\n

1 namespace Dojo\\ClassifyDocument;\n2 \n3 \n4 use DateTime;\n5 \n6 interface CalculateSchoolYear\n7 {\n8     public function forDate(DateTime $dateTime) : string;\n9 }\n

\n\n\n\n

Solo para que conste: personalmente no soy partidario de añadir el sufijo Interface. La interfaz representa el concepto, y las implementaciones serían formas concretas, cuyo nombre podría indicarnos su tipo concreto. Podría ocurrir que sólo tiene sentido una implementación concreta de ese servicio, con lo cual desaparecería la interfaz, la implementación sería genérica y, como bonus, no tendría que cambiar nada más.

\n\n

Un stub es un test double que tiene una respuesta programada a ciertos mensajes que le enviamos, así que lo introducimos en nuestro test y veremos a qué nos lleva:

\n\n

 1     public function testSchoolYearForFirstQuarterIsTheSameYear()\n 2     {\n 3         $classifyDocumentRequest = new ClassifyDocumentRequest(\n 4             '5433',\n 5             'Matemáticas',\n 6             'deberes',\n 7             'misejercicioschupiguais.pdf',\n 8             new DateTime('2018-10-12')\n 9         );\n10         $calculateSchoolYear = $this->prophesize(CalculateSchoolYear::class);\n11         $calculateSchoolYear->forDate(new DateTime('2018-10-12'))->willReturn('2018-\\\n12 2019');\n13 \n14         $classifyDocumentService = new ClassifyDocument($calculateSchoolYear->reveal\\\n15 ());\n16         $route = $classifyDocumentService->execute($classifyDocumentRequest);\n17         $this->assertEquals('2018-2019', $route);\n18     }\n

\n\n\n\n

Como este test falla, podemos empezar a implementar lo necesario:

\n\n

 1 namespace Dojo\\ClassifyDocument;\n 2 \n 3 \n 4 class ClassifyDocument\n 5 {\n 6     /**\n 7      * @var CalculateSchoolYear\n 8      */\n 9     private $calculateSchoolYear;\n10 \n11     /**\n12      * ClassifyDocument constructor.\n13      */\n14     public function __construct(CalculateSchoolYear $calculateSchoolYear)\n15     {\n16         $this->calculateSchoolYear = $calculateSchoolYear;\n17     }\n18 \n19     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n20 ng\n21     {\n22         $date = $classifyDocumentRequest->dateTime();\n23         $schoolYear = $this->calculateSchoolYear->forDate($date);\n24         return $schoolYear;\n25     }\n26 }\n

\n\n\n\n

Una vez implementado esto vemos que pasan dos cosas:

\n\n

El nuevo test pasa.
El test que ya existía no pasa porque no contempla el hecho de haber introducido el servicio CalculateSchoolYear.

\n\n

Así que arreglamos eso para que pase, cuidando de ajustar los nuevos valores del stub.

\n\n

 1 namespace Tests\\Dojo\\ClassifyDocument;\n 2 \n 3 use DateTime;\n 4 use Dojo\\ClassifyDocument\\ClassifyDocument;\n 5 use Dojo\\ClassifyDocument\\ClassifyDocumentRequest;\n 6 use Dojo\\ClassifyDocument\\CalculateSchoolYear;\n 7 use PHPUnit\\Framework\\TestCase;\n 8 \n 9 class ClassifyDocumentTest extends TestCase\n10 {\n11 \n12     public function testSchoolYearIsTheFirstElementOfTheRoute()\n13     {\n14         $classifyDocumentRequest = new ClassifyDocumentRequest(\n15             '5433',\n16             'Matemáticas',\n17             'deberes',\n18             'misejercicioschupiguais.pdf',\n19             new DateTime('2018-03-12')\n20         );\n21         $calculateSchoolYear = $this->prophesize(CalculateSchoolYear::class);\n22         $calculateSchoolYear->forDate(new DateTime('2018-03-12'))->willReturn('2017-\\\n23 2018');\n24 \n25         $classifyDocumentService = new ClassifyDocument($calculateSchoolYear->reveal\\\n26 ());\n27         $route = $classifyDocumentService->execute($classifyDocumentRequest);\n28         $this->assertEquals('2017-2018', $route);\n29     }\n30 \n31     public function testSchoolYearForFirstQuarterIsTheSameYear()\n32     {\n33         $classifyDocumentRequest = new ClassifyDocumentRequest(\n34             '5433',\n35             'Matemáticas',\n36             'deberes',\n37             'misejercicioschupiguais.pdf',\n38             new DateTime('2018-10-12')\n39         );\n40         $calculateSchoolYear = $this->prophesize(CalculateSchoolYear::class);\n41         $calculateSchoolYear->forDate(new DateTime('2018-10-12'))->willReturn('2018-\\\n42 2019');\n43 \n44         $classifyDocumentService = new ClassifyDocument($calculateSchoolYear->reveal\\\n45 ());\n46         $route = $classifyDocumentService->execute($classifyDocumentRequest);\n47         $this->assertEquals('2018-2019', $route);\n48     }\n49 }\n

\n\n\n\n

Estupendo. Ahora podemos observar varias cosas.

\n\n

La construcción del servicio bajo test ClassifyDocument estaría mejor en un único lugar.
Hay varios valores que se utilizan repetidas veces, por lo que sería buena idea unificarlos de algún modo, lo que nos daría mayor seguridad de que estamos testeando lo que queremos.

\n\n

Así que vamos a arreglar eso antes de nada, para que sea más fácil seguir adelante con el desarrollo. Para eso tenemos que mantener los tests en verde, señal de que no hemos roto nada.

\n\n

 1 namespace Tests\\Dojo\\ClassifyDocument;\n 2 \n 3 use DateTime;\n 4 use Dojo\\ClassifyDocument\\ClassifyDocument;\n 5 use Dojo\\ClassifyDocument\\ClassifyDocumentRequest;\n 6 use Dojo\\ClassifyDocument\\CalculateSchoolYear;\n 7 use PHPUnit\\Framework\\TestCase;\n 8 \n 9 class ClassifyDocumentTest extends TestCase\n10 {\n11     private $classifyDocumentService;\n12     private $calculateSchoolYear;\n13 \n14     private const DEFAULT_STUDENT_ID = '5433';\n15     private const DEFAULT_SUBJECT = 'Matemáticas';\n16     private const DEFAULT_TYPE = 'deberes';\n17     private const DEFAULT_FILE = 'misejercicioschupiguais.pdf';\n18     private const DEFAULT_UPLOAD_DATE = '2018-03-12';\n19     \n20     private const DEFAULT_SCHOOL_YEAR = '2017-2018';\n21 \n22     public function setUp()\n23     {\n24         $this->calculateSchoolYear = $this->prophesize(CalculateSchoolYear::class);\n25         $this->calculateSchoolYear->forDate(new DateTime(self::DEFAULT_UPLOAD_DATE))\\\n26 ->willReturn(self::DEFAULT_SCHOOL_YEAR);\n27         $this->classifyDocumentService = new ClassifyDocument($this->calculateSchool\\\n28 Year->reveal());\n29     }\n30 \n31     public function testSchoolYearIsTheFirstElementOfTheRoute()\n32     {\n33         $classifyDocumentRequest = new ClassifyDocumentRequest(\n34             self::DEFAULT_STUDENT_ID,\n35             self::DEFAULT_SUBJECT,\n36             self::DEFAULT_TYPE,\n37             self::DEFAULT_FILE,\n38             new DateTime(self::DEFAULT_UPLOAD_DATE)\n39         );\n40         \n41         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n42         $this->assertEquals(self::DEFAULT_SCHOOL_YEAR, $route);\n43     }\n44 \n45     public function testSchoolYearForFirstQuarterIsTheSameYear()\n46     {\n47         $uploadDate = '2018-10-12';\n48         $schoolYear = '2018-2019';\n49 \n50         $classifyDocumentRequest = new ClassifyDocumentRequest(\n51             self::DEFAULT_STUDENT_ID,\n52             self::DEFAULT_SUBJECT,\n53             self::DEFAULT_TYPE,\n54             self::DEFAULT_FILE,\n55             new DateTime($uploadDate)\n56         );\n57 \n58         $this->calculateSchoolYear->forDate(new DateTime($uploadDate))->willReturn($\\\n59 schoolYear);\n60 \n61         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n62         $this->assertEquals($schoolYear, $route);\n63     }\n64 }\n

\n\n\n\n

Ahora está un poquito mejor, así que: ¡sigamos adelante!

\n\n

TDD de la Etapa Educativa

\n\n

En el sistema educativo español hay varias etapas educativas, como son Infantil, Primaria, Secundaria o Bachillerato. Cada etapa se divide, a su vez, en niveles educativos, que es lo que solemos llamar “cursos”. Lo cierto es que para expresar con propiedad el curso en el que se encuentra un estudiante concreto siempre tendríamos que decir a qué etapa pertenece, como 3º de Primaria, 4º de Secundaria, 1º de Infantil, etc.

\n\n

Pero no estamos aquí para diseñar aplicaciones educativas sino para explicar TDD. Sin embargo, la parrafada anterior es necesaria para entender que ahora nos toca generar el fragmento de ruta que representa la etapa educativa, y esa información la podremos obtener sabiendo curso en el que se encuentre matriculado nuestro estudiante, Por tanto, necesitaremos obtener un objeto Student al cual preguntarle todos esos datos.

\n\n

En nuestro diseño, seguramente Student sea un agregado, una Entidad que incluye diversas entidades y value objects relacionados con una determinada identidad. Para obtener nuestro estudiante concreto preguntaremos a un repositorio de estudiantes por aquél cuya identidad viene especificada en la request. Para simplificar, vamos a imaginar que nuestra clase Student es más o menos así (sí, soy consciente de que simplifico mucho):

\n\n

 1 namespace Dojo\\ClassifyDocument;\n 2 \n 3 class Student\n 4 {\n 5     /**\n 6      * @var string\n 7      */\n 8     private $id;\n 9     /**\n10      * @var string\n11      */\n12     private $name;\n13     /**\n14      * @var string\n15      */\n16     private $level;\n17     /**\n18      * @var string\n19      */\n20     private $stage;\n21     /**\n22      * @var string\n23      */\n24     private $group;\n25 \n26     public function __construct(string $id, string $name, string $level, string $sta\\\n27 ge, string $group)\n28     {\n29         $this->id = $id;\n30         $this->name = $name;\n31         $this->level = $level;\n32         $this->stage = $stage;\n33         $this->group = $group;\n34     }\n35 \n36     /**\n37      * @return string\n38      */\n39     public function Id() : string\n40     {\n41         return $this->id;\n42     }\n43 \n44     /**\n45      * @return string\n46      */\n47     public function Name() : string\n48     {\n49         return $this->name;\n50     }\n51 \n52     /**\n53      * @return string\n54      */\n55     public function Level() : string\n56     {\n57         return $this->level;\n58     }\n59 \n60     /**\n61      * @return string\n62      */\n63     public function Stage() : string\n64     {\n65         return $this->stage;\n66     }\n67 \n68     /**\n69      * @return string\n70      */\n71     public function Group() : string\n72     {\n73         return $this->group;\n74     }\n75 }\n

\n\n\n\n

Además, contamos con un repositorio de Student que tiene esta interfaz, la cual me servirá para generar un nuevo stub:

\n\n

1 <?php\n2 namespace Dojo\\ClassifyDocument;\n3 \n4 \n5 interface StudentRepository\n6 {\n7     public function byId(string $id): Student;\n8 }\n

\n\n\n\n

Bien, pues dando por supuesto que disponemos de estas clases, vamos a crear un test que falle, asumiendo que nuestro servicio va a necesitar el StudentRepository para obtener un objeto Student a partir de su Id.

\n\n

El test va a quedar más o menos así:

\n\n

 1     public function testStageIstheSecondFolderLevel()\n 2     {\n 3         $expectedStage = 'primaria';\n 4 \n 5         $classifyDocumentRequest = new ClassifyDocumentRequest(\n 6             self::DEFAULT_STUDENT_ID,\n 7             self::DEFAULT_SUBJECT,\n 8             self::DEFAULT_TYPE,\n 9             self::DEFAULT_FILE,\n10             new DateTime(self::DEFAULT_UPLOAD_DATE)\n11         );\n12 \n13         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n14         \n15         [, $stage] = explode('/', $route);\n16         $this->assertEquals($expectedStage, $stage);\n17     }\n

\n\n\n\n

Por supuesto, no va a pasar.

\n\n

Ahora tenemos la habitual disyuntiva de hacer la implementación más simple y obvia que es devolver el valor que esperamos y escribir un nuevo test que nos obligue a implementar una solución general; o bien ir directamente a esa solución general.

\n\n

En esta ocasión me voy a decantar por la primera opción porque, como se puede apreciar, se van a romper los test anteriores, por lo que prefiero solucionar eso antes. Pero para ello, necesito que este test pase.

\n\n

 1 class ClassifyDocument\n 2 {\n 3     /**\n 4      * @var CalculateSchoolYear\n 5      */\n 6     private $calculateSchoolYear;\n 7 \n 8     /**\n 9      * ClassifyDocument constructor.\n10      */\n11     public function __construct(CalculateSchoolYear $calculateSchoolYear)\n12     {\n13         $this->calculateSchoolYear = $calculateSchoolYear;\n14     }\n15 \n16     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n17 ng\n18     {\n19         $date = $classifyDocumentRequest->dateTime();\n20         $schoolYear = $this->calculateSchoolYear->forDate($date);\n21         return $schoolYear.'/primaria';\n22     }\n23 }\n

\n\n\n\n

Ahí lo tenemos: nuestro test actual pasa, pero rompemos los anteriores. Así que voy a arreglarlos:

\n\n

 1 public function testSchoolYearIsTheFirstElementOfTheRoute()\n 2     {\n 3         $classifyDocumentRequest = new ClassifyDocumentRequest(\n 4             self::DEFAULT_STUDENT_ID,\n 5             self::DEFAULT_SUBJECT,\n 6             self::DEFAULT_TYPE,\n 7             self::DEFAULT_FILE,\n 8             new DateTime(self::DEFAULT_UPLOAD_DATE)\n 9         );\n10 \n11         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n12         \n13         [$schoolYear] = explode('/', $route);\n14         $this->assertEquals(self::DEFAULT_SCHOOL_YEAR, $schoolYear);\n15     }\n16 \n17     public function testSchoolYearForFirstQuarterIsTheSameYear()\n18     {\n19         $uploadDate = '2018-10-12';\n20         $schoolYear = '2018-2019';\n21 \n22         $classifyDocumentRequest = new ClassifyDocumentRequest(\n23             self::DEFAULT_STUDENT_ID,\n24             self::DEFAULT_SUBJECT,\n25             self::DEFAULT_TYPE,\n26             self::DEFAULT_FILE,\n27             new DateTime($uploadDate)\n28         );\n29 \n30         $this->calculateSchoolYear->forDate(new DateTime($uploadDate))->willReturn($\\\n31 schoolYear);\n32 \n33         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n34         \n35         [$schoolYear] = explode('/', $route);\n36         $this->assertEquals($schoolYear, $schoolYear);\n37     }\n

\n\n\n\n

¿Ha molado o no ha molado?

\n\n

Fíjate con esta técnica obtengo exactamente el fragmento de la ruta que quiero, sin tener que prestar atención al resto de la cadena que me devuelve.

\n\n

1     [$schoolYear] = explode('/', $route);\n2     [, $stage] = explode('/', $route);\n

\n\n\n\n

Esto es lo que quería señalar, ahora nuestros tests están mirando sólo una parte del algoritmo cada vez. Si en el futuro se rompe alguno, sabré exactamente qué parte ha sido afectada.

\n\n

Sigamos:

\n\n

Nuestra última implementación inflexible necesita un masaje… quiero decir: necesita un nuevo test que, fallando, nos fuerce a implementar una solución más general:

\n\n

 1     public function testStageIstheSecondFolderLevelAndMayVary()\n 2     {\n 3         $expectedStage = 'secundaria';\n 4         $studentId = 6745;\n 5 \n 6         $classifyDocumentRequest = new ClassifyDocumentRequest(\n 7             $studentId,\n 8             self::DEFAULT_SUBJECT,\n 9             self::DEFAULT_TYPE,\n10             self::DEFAULT_FILE,\n11             new DateTime(self::DEFAULT_UPLOAD_DATE)\n12         );\n13 \n14         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n15 \n16         [, $stage] = explode('/', $route);\n17         $this->assertEquals($expectedStage, $stage);\n18     }\n

\n\n\n\n

El test falla y para hacerlo pasar necesitamos obtener de algún sitio la etapa educativa. Como hemos visto antes, podemos averiguarla preguntando a Student el cual, a su vez, podemos obtener pidiéndolo al StudentRepository mediante su Id, el cual conocemos.

\n\n

Para ello, nos vamos al método setUp generamos y montamos el stub.

\n\n

 1     public function setUp()\n 2     {\n 3         $this->calculateSchoolYear = $this->prophesize(\n 4             CalculateSchoolYear::class\n 5         );\n 6         $this->calculateSchoolYear\n 7             ->forDate(new DateTime(self::DEFAULT_UPLOAD_DATE))\n 8             ->willReturn(self::DEFAULT_SCHOOL_YEAR);\n 9 \n10         $this->studentRepository = $this->prophesize(\n11             StudentRepository::class\n12         );\n13 \n14         $this->studentRepository->byId(self::DEFAULT_STUDENT_ID)\n15             ->willReturn(new Student(\n16                 self::DEFAULT_STUDENT_ID,\n17                 'Pepito',\n18                 '5',\n19                 'primaria',\n20                 '5C'\n21             ));\n22         $this->classifyDocumentService = new ClassifyDocument(\n23             $this->calculateSchoolYear->reveal(),\n24             $this->studentRepository->reveal()\n25         );\n26     }\n

\n\n\n\n

El stub por sí mismo no va hacer que pasemos el test. Necesitaremos implementar algo, pero antes me gustaría llamar tu atención sobre un detalle.

\n\n

En el setUp programo los stubs para que devuelva algunos valores específicos para los datos por defecto. Para probar con otros valores, no tengo más que programar en los métodos de test concretos los nuevos, como se puede ver en el ejemplo anterior.

\n\n

De este modo, intento tener siempre un caso por defecto y generar otros casos a medida que los necesite. Lo cual quiere decir que en el test, tengo que programar una nueva respuesta en el stub, que devuelva un Student que sí nos haga cumplir los requisitos del test:

\n\n

 1     public function testStageIstheSecondFolderLevelAndMayVary()\n 2     {\n 3         $expectedStage = 'secundaria';\n 4         $studentId = 6745;\n 5 \n 6         $this->studentRepository->byId($studentId)\n 7             ->willReturn(new Student(\n 8                 $studentId,\n 9                 'Pepito',\n10                 '4',\n11                 $expectedStage,\n12                 '4C'\n13             ));\n14         \n15         $classifyDocumentRequest = new ClassifyDocumentRequest(\n16             $studentId,\n17             self::DEFAULT_SUBJECT,\n18             self::DEFAULT_TYPE,\n19             self::DEFAULT_FILE,\n20             new DateTime(self::DEFAULT_UPLOAD_DATE)\n21         );\n22 \n23         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n24 \n25         [, $stage] = explode('/', $route);\n26         $this->assertEquals($expectedStage, $stage);\n27     }\n

\n\n\n\n

El test sigue fallando porque realmente no hemos implementado nada todavía, lo que no debería darnos muchos problemas:

\n\n

 1 class ClassifyDocument\n 2 {\n 3     /**\n 4      * @var CalculateSchoolYear\n 5      */\n 6     private $calculateSchoolYear;\n 7     /**\n 8      * @var StudentRepository\n 9      */\n10     private $studentRepository;\n11 \n12     /**\n13      * ClassifyDocument constructor.\n14      */\n15     public function __construct(\n16         CalculateSchoolYear $calculateSchoolYear,\n17         StudentRepository $studentRepository\n18     ) {\n19         $this->calculateSchoolYear = $calculateSchoolYear;\n20         $this->studentRepository = $studentRepository;\n21     }\n22 \n23     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n24 ng\n25     {\n26         $date = $classifyDocumentRequest->dateTime();\n27         $schoolYear = $this->calculateSchoolYear->forDate($date);\n28 \n29         $student = $this->studentRepository->byId(\n30             $classifyDocumentRequest->studentId()\n31         );\n32         return $schoolYear.'/'.$student->Stage();\n33     }\n34 }\n

\n\n\n\n

Con esto, el test ya pasa y podemos irnos al siguiente fragmento de la ruta:

\n\n

TDD del nivel educativo

\n\n

La siguiente parte de la ruta es el nivel educativo. A partir de ahora vamos a ir más rápido, en parte porque vamos a hacer pasos un poco más grandes ya que los elementos que vienen son bastante sencillos.

\n\n

Como siempre, con los tests en verde podríamos ver si tenemos oportunidades de refactorizar. De momento, no hay nada que me llame la atención, así que voy a pasar al siguiente test que falle:

\n\n

 1     public function testlevelIstheThirdFolderLevel()\n 2     {\n 3         $classifyDocumentRequest = new ClassifyDocumentRequest(\n 4             $studentId,\n 5             self::DEFAULT_SUBJECT,\n 6             self::DEFAULT_TYPE,\n 7             self::DEFAULT_FILE,\n 8             new DateTime(self::DEFAULT_UPLOAD_DATE)\n 9         );\n10 \n11         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n12 \n13         [, , $level] = explode('/', $route);\n14         $this->assertEquals('5', $level);\n15     }\n

\n\n\n

Y, a continuación, la implementación para que pase el test que, gracias a lo que hicimos para la etapa educativa, ahora es bastante trivial:

\n\n

 1 class ClassifyDocument\n 2 {\n 3     /**\n 4      * @var CalculateSchoolYear\n 5      */\n 6     private $calculateSchoolYear;\n 7     /**\n 8      * @var StudentRepository\n 9      */\n10     private $studentRepository;\n11 \n12     /**\n13      * ClassifyDocument constructor.\n14      */\n15     public function __construct(\n16         CalculateSchoolYear $calculateSchoolYear,\n17         StudentRepository $studentRepository\n18     ) {\n19         $this->calculateSchoolYear = $calculateSchoolYear;\n20         $this->studentRepository = $studentRepository;\n21     }\n22 \n23     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n24 ng\n25     {\n26         $date = $classifyDocumentRequest->dateTime();\n27         $schoolYear = $this->calculateSchoolYear->forDate($date);\n28 \n29         $student = $this->studentRepository->byId(\n30             $classifyDocumentRequest->studentId()\n31         );\n32         return $schoolYear.'/'.$student->Stage().'/'.$student->Level();\n33     }\n34 }\n

\n\n\n\n

Y ya tenemos el test pasando.

\n\n

Ahora vemos que lo que queda un poco feo es la concatenación de los fragmentos con el separador de directorios. La verdad es que podemos hacerlo algo mejor y más bonito. Como tenemos los tests pasando, podemos trabajar con tranquilidad:

\n\n

 1 namespace Dojo\\ClassifyDocument;\n 2 \n 3 class ClassifyDocument\n 4 {\n 5     /**\n 6      * @var CalculateSchoolYear\n 7      */\n 8     private $calculateSchoolYear;\n 9     /**\n10      * @var StudentRepository\n11      */\n12     private $studentRepository;\n13 \n14     /**\n15      * ClassifyDocument constructor.\n16      */\n17     public function __construct(\n18         CalculateSchoolYear $calculateSchoolYear,\n19         StudentRepository $studentRepository\n20     ) {\n21         $this->calculateSchoolYear = $calculateSchoolYear;\n22         $this->studentRepository = $studentRepository;\n23     }\n24 \n25     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n26 ng\n27     {\n28         $date = $classifyDocumentRequest->dateTime();\n29         $schoolYear = $this->calculateSchoolYear->forDate($date);\n30 \n31         $student = $this->studentRepository->byId(\n32             $classifyDocumentRequest->studentId()\n33         );\n34 \n35         $route = [\n36             $schoolYear,\n37             $student->Stage(),\n38             $student->Level()\n39         ];\n40         return implode(DIRECTORY_SEPARATOR, $route);\n41     }\n42 }\n

\n\n\n\n

Con esto, no sólo sigue pasando el test, sino que es mucho más elegante y clara la forma de montar la URL.

\n\n

TDD del grupo

\n\n

Lo mismo que hemos dicho antes se aplica a continuación. Primero, test que falle al canto:

\n\n

 1     public function testGroupIstheFourthFolderLevel()\n 2     {\n 3         $classifyDocumentRequest = new ClassifyDocumentRequest(\n 4             self::DEFAULT_STUDENT_ID,\n 5             self::DEFAULT_SUBJECT,\n 6             self::DEFAULT_TYPE,\n 7             self::DEFAULT_FILE,\n 8             new DateTime(self::DEFAULT_UPLOAD_DATE)\n 9         );\n10 \n11         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n12 \n13         [, , , $group] = explode('/', $route);\n14         $this->assertEquals('5C', $group);\n15     }\n

\n\n\n\n

Test en rojo: a implementar se ha dicho, pero ahora ya es muy fácil:

\n\n

 1 namespace Dojo\\ClassifyDocument;\n 2 \n 3 \n 4 class ClassifyDocument\n 5 {\n 6     /**\n 7      * @var CalculateSchoolYear\n 8      */\n 9     private $calculateSchoolYear;\n10     /**\n11      * @var StudentRepository\n12      */\n13     private $studentRepository;\n14 \n15     /**\n16      * ClassifyDocument constructor.\n17      */\n18     public function __construct(\n19         CalculateSchoolYear $calculateSchoolYear,\n20         StudentRepository $studentRepository\n21     ) {\n22         $this->calculateSchoolYear = $calculateSchoolYear;\n23         $this->studentRepository = $studentRepository;\n24     }\n25 \n26     public function execute(ClassifyDocumentRequest $classifyDocumentRequest) : stri\\\n27 ng\n28     {\n29         $date = $classifyDocumentRequest->dateTime();\n30         $schoolYear = $this->calculateSchoolYear->forDate($date);\n31 \n32         $student = $this->studentRepository->byId(\n33             $classifyDocumentRequest->studentId()\n34         );\n35 \n36         $route = [\n37             $schoolYear,\n38             $student->Stage(),\n39             $student->Level(),\n40             $student->Group()\n41         ];\n42         return implode(DIRECTORY_SEPARATOR, $route);\n43     }\n44 }\n

\n\n\n\n

TDD el resto de la ruta

\n\n

Para nuestro ejemplo no he querido complicarme mucho, por lo que nos vamos a encontrar con que el resto de elementos de la ruta son fáciles de implementar y la forma de hacerlo ahora es bastante evidente.

\n\n

Por esa razón, no voy a alargar más el artículo y voy a pasar directamente al resultado final y las conclusiones.

\n\n

En todo caso, para llegar al final no tenemos más que seguir con nuestro ciclo de siempre: test que falla, implementar hasta conseguir que pase, refactorizar y seguir. El punto final lo tendremos cuando el test de aceptación pase.

\n\n

Evidentemente, el test de aceptación tal y como estaba escrito originalmente no nos va a servir porque en ese momento no teníamos en cuenta que íbamos a necesitar colaboradores, por lo que tendremos que modificarlo e incluirlos.

\n\n

Ese test nos va a quedar más o menos así:

\n\n

 1 namespace Tests\\Dojo\\ClassifyDocument\\Application;\n 2 \n 3 use DateTime;\n 4 use Dojo\\ClassifyDocument\\Application\\ClassifyDocument;\n 5 use Dojo\\ClassifyDocument\\Application\\ClassifyDocumentRequest;\n 6 use Dojo\\ClassifyDocument\\Application\\CalculateSchoolYear;\n 7 use Dojo\\ClassifyDocument\\Domain\\Student;\n 8 use Dojo\\ClassifyDocument\\Domain\\StudentRepository;\n 9 use PHPUnit\\Framework\\TestCase;\n10 \n11 class ClassifyDocumentAcceptanceTest extends TestCase\n12 {\n13     private const DEFAULT_STUDENT_ID = '5433';\n14     private const DEFAULT_SUBJECT = 'Matemáticas';\n15     private const DEFAULT_TYPE = 'deberes';\n16     private const DEFAULT_FILE = 'misejercicioschupiguais.pdf';\n17     private const DEFAULT_UPLOAD_DATE = '2018-03-12';\n18 \n19     private const DEFAULT_SCHOOL_YEAR = '2017-2018';\n20 \n21     public function setUp()\n22     {\n23         $this->calculateSchoolYear = $this->prophesize(\n24             CalculateSchoolYear::class\n25         );\n26         $this->calculateSchoolYear\n27             ->forDate(new DateTime(self::DEFAULT_UPLOAD_DATE))\n28             ->willReturn(self::DEFAULT_SCHOOL_YEAR);\n29 \n30         $this->studentRepository = $this->prophesize(\n31             StudentRepository::class\n32         );\n33 \n34         $this->studentRepository->byId(self::DEFAULT_STUDENT_ID)\n35             ->willReturn(new Student(\n36                 self::DEFAULT_STUDENT_ID,\n37                 'Pepito',\n38                 '5',\n39                 'primaria',\n40                 '5C'\n41             ));\n42         $this->classifyDocumentService = new ClassifyDocument(\n43             $this->calculateSchoolYear->reveal(),\n44             $this->studentRepository->reveal()\n45         );\n46     }\n47 \n48     public function testValidRequestShouldGenerateRoute()\n49     {\n50         $classifyDocumentRequest = new ClassifyDocumentRequest(\n51             self::DEFAULT_STUDENT_ID,\n52             self::DEFAULT_SUBJECT,\n53             self::DEFAULT_TYPE,\n54             self::DEFAULT_FILE,\n55             new DateTime(self::DEFAULT_UPLOAD_DATE)\n56         );\n57         $route = $this->classifyDocumentService->execute($classifyDocumentRequest);\n58         $expected = '2017-2018/primaria/5/5C/matemáticas/5433/2018-03-12-deberes.pdf\\\n59 ';\n60         $this->assertEquals($expected, $route);\n61     }\n62 }\n

\n\n\n

En cualquier caso, puedes ver el código en este repositorio. Seguramente podrás observar algunos refinamientos y mejoras de nombres que no están reflejados en el código de este artículo.

\n\n

Conclusiones

\n\n

Lo que he tratado de mostrar en este ejercicio es que TDD no consiste sólo en hacer tests antes de escribir el código.

\n\n

Para que podamos hablar de TDD, los tests tienen que generarnos la necesidad de implementar, impulsando el desarrollo de cada característica de nuestro software.

\n\n

Si haces TDD a ritmo de baby steps de manera que cada paso te fuerce a implementar la solución más simple, primero, y a refactorizar en busca de un buen diseño, lo cierto es que puedes tener que hacer bastantes tests:

\n\n

El primero para hacer una implementación “tonta” e inflexible: el típico devolver exactamente lo que esperas.
El segundo para provocar que la implementación inflexible falle e implementar una solución sencilla, aunque no sea del todo genérica.
Un tercer test que ponga en cuestión la solución anterior y nos lleve a una más genérica. n este punto seguramente ya podríamos empezar a refactorizar para mejorar el diseño
Además, podrían haber aparecido casos límite que no pueden tratarse con la solución general y tendrían un test específico.

\n\n

En cualquier caso esto va a depender del tamaño de los baby steps que decidamos tomar, que dependen de nuestra experiencia, del conocimiento que tengamos de la tarea, etc.

\n\n

Ahora, en la práctica creo que es perfectamente válido desechar algunos de estos tests si no aportan información extra con el objetivo de aligerar nuestras Suites de Tests. Puedes contemplarlo como un caso de duplicación, y ya sabemos que la duplicación innecesaria hay que eliminarla. Se trataría de dejar los tests que nos podrían funcionar como tests de regresión.

\n\n

Podemos ver TDD como una metodología iterativa: empezamos con unos requerimientos muy sencillos: que exista una clase, que tenga cierto método, que devuelva un cierto resultado… Cada vez, un nuevo requisito, intentando no ver más allá del problema actual.

\n\n

En algún momento esto podría alterar el resultado que necesitamos que devuelva nuestra unidad y, por tanto, podríamos vernos en la necesidad de modificar el test. Pero esto ocurre porque nos forzamos a no adelantar acontecimientos, incluso aunque nosotros “sabemos” que nuestra clase va a necesitar colaboradores o que va a cambiar la forma en que devuelve los resultados. Pero en TDD queremos que esas cosas nos las digan los tests.

\n\n\n

Usar el code coverage para mejorar los tests

\n\n

El code coverage es una métrica que conviene coger con pinzas y examinar con mucho cuidado.

\n\n

En principio, el code coverage nos indica las líneas de código cubiertas por la ejecución de tests y lo deseable sería, sobre el papel, acercarnos lo más posible al 100%.

\n\n

Por desgracia, una medida alta de coverage no garantiza que los tests prueben adecuadamente el comportamiento de las unidades de softwware. En ese sentido, es muy fácil incluso falsear la métrica con tests que ejerciten las líneas de código pero que realmente no demuestren gran cosa sobre el mismo.

\n\n

Además, ni siquiera una cobertura del 100% garantiza realmente que todos los casos han sido probados.

\n\n

Por otra parte, la cobertura total es bastante difícil de conseguir en una base de código que no cuente todavía con tests. Entre otras cosas, porque tampoco es un objetivo deseable, ya que hay muchas partes de una aplicación que ni siquiera merece la pena considerar testear porque el código es trivial o porque el único tipo de test posible resultaría muy frágil.

\n\n

En realidad, creo que sólo desarrollando con TDD se conseguiría una cobertura completa, pero como consecuencia de la metodología y no porque nos la planteemos como objetivo. Y esto es así porque, por definición, el código de producción sólo se escribe con el objetivo de hacer pasar un test.

\n\n

En todo caso, y a pesar de estas observaciones, mejorar el nivel de cobertura de tests de una base de código es un objetivo que merece la pena.

\n\n

Además, el análisis del code coverage es una buena herramienta para ayudarnos a escribir mejores tests, especialmente en situaciones de refactoring de código legacy.

\n\n

Así que he extraído algún material de un artículo anterior y las desarrollo aquí un poco mejor.

\n\n

Code coverage y refactoring

\n\n

Además de lo que podríamos denominar análisis “a ojímetro” y del uso del depurador, las herramientas de Code Coverage nos pueden ayudar mucho en el refactoring al permitirnos detectar aquellas partes del código cuyo comportamiento no hayamos descrito todavía.

\n\n

PHPUnit nos proporciona todo lo necesario, pero primero tendremos que condigurarlo:

\n\n

Preparar el entorno para disponer de análisis de Code Coverage

\n\n

Por una parte, vamos a crear un archivo de configuración de phpunit. Podemos hacerlo mediante el siguiente comando en shell en la raíz del proyecto:

\n\n

1 bin/phpunit --generate-configuration\n

\n\n\n\n

Este comando es interactivo y nos pedirá confirmar algunos valores según nuestro proyecto:

\n\n

1 Bootstrap script (relative to path shown above; default: vendor/autoload.php): \n2 Tests directory (relative to path shown above; default: tests): \n3 Source directory (relative to path shown above; default: src): \n

\n\n\n\n

Bootstrap script se ejecutará antes de los tests y nos permitiría, como en el ejemplo, lanzar el autoloader, para disponer de la autocarga de clases a través del namespace o como lo hayamos configurado en nuestro composer.json.

\n\n

Tests directory indica dónde se encuentran los tests.

\n\n

Source directory es la ubicación del código.

\n\n

Lo siguiente será modificar un poco el archivo resultante ya que, por defecto, activa el uso de la anotación @covers que se usa para indicar explícitamente el código del que queremos obtener informe de cobertura. Por tanto, podremos el atributo forceCoversAnnotion en false, para así poder aplicar el análisis a todo el código, poniendo en whitelist nuestra carpeta src:

\n\n

 1 <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n 2 <phpunit xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n 3          xsi:noNamespaceSchemaLocation=\"https://schema.phpunit.de/6.5/phpunit.xsd\"\n 4          bootstrap=\"vendor/autoload.php\"\n 5          forceCoversAnnotation=\"false\"\n 6          beStrictAboutCoversAnnotation=\"true\"\n 7          beStrictAboutOutputDuringTests=\"true\"\n 8          beStrictAboutTodoAnnotatedTests=\"true\"\n 9          verbose=\"true\">\n10     <testsuite name=\"default\">\n11         <directory suffix=\"Test.php\">tests</directory>\n12     </testsuite>\n13     <filter>\n14         <whitelist processUncoveredFilesFromWhitelist=\"true\">\n15             <directory suffix=\".php\">src</directory>\n16         </whitelist>\n17     </filter>\n18 </phpunit>\n

\n\n\n\n

Con esto, podremos ejecutar phpunit con el informe de coverage que más nos convenga:

\n\n

1 bin/phpunit --coverage-html ./coverage\n

\n\n\n\n

La línea anterior generará un informe de cobertura en Html creando la carpeta coverage si no existe. Abriendo el index.html en un navegador podremos acceder a él.

\n\n

En PHPStorm podemos crear una configuración para test indicando simplemente que use el archivo de configuración alternativo que acabamos de crear. Ejecutando los tests con coverage, el propio IDE nos mostrará qué líneas están cubiertas y cuántas no, usando colores verdes y rojo respectivamente. Además, nos mostrará el número de veces que se ejecuta cada línea.

\n\n

Cómo usar el Code Coverage para crear tests de caracterización

\n\n

Líneas rojas por las que hay que pasar

\n\n

La forma más obvia de utilizar Code Coverage para crear tests de caracterización es detectar líneas de código por las que no pasa el flujo de ejecución cuando lanzamos los test.

\n\n

Las líneas marcadas en rojo nos indican que por ahí no hemos pasado, en consecuencia, necesitamos crear un test que requiera su ejecución para pasar.

\n\n

El número de pases también cuenta

\n\n

En algunos casos, el hecho de que la línea se haya ejecutado no garantiza que el caso esté bien cubierto. Para eso nos fijamos en el número de hits, como los denomina PHPStorm, que no es más que el número de tests cuya ejecución pasa por esa línea.

\n\n

En el caso de una línea o bloque cuya ejecución depende de una combinación de condiciones, tenemos que comprobar que el número de hits es, al menos, igual que el número de posibles resultados de la expresión condicional.

\n\n

Veámoslo más en detalle:

\n\n

Condicion1 AND Condicion2: para ejecutar un bloque controlado por esta condicional se tiene que dar un caso en el que se cumplen ambas partes. Por otro lado, también tendríamos que probar el caso de que no se cumple toda la condicional.

\n\n

Por tanto, para garantizar que esté bien cubierto, y sabiendo que el bloque ha de ejecutarse como mínimo una vez, el número de hits de la expresión condicional ha de ser mayor o igual a dos: en un caso se cumple la expresión condicional y en otro no se cumple. En la siguiente tabla se pueden ver todos los casos:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Condición 1	Condición 2	Resultado	¿Se ejecuta?
true	true	true	Sí
true	false	false	No
false	true	false	No
false	false	false	No

\n\n

Condicion1 OR Condicion2: en este caso el bloque bajo la expresión condicional se ejecutará si al menos una de las dos condiciones se cumple. Para cubrirlo completamente, necesitamos que la expresión se ejecute cuatro veces y el bloque que controla, lo haga al menos tres veces.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Condición 1	Condición 2	Resultado	¿Se ejecuta?
true	true	true	Sí
true	false	true	Sí
false	true	true	Sí
false	false	false	No

\n\n

Condición negada las expresiones condicionales de negación deberían ejecutarse dos veces y el bloque que controlan al menos una vez.

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n

Condición 1	Resultado	¿Se ejecuta?
true	false	No
false	true	Sí

\n\n

A partir de aquí, las expresiones condicionales complejas requerirán un número de hits acorde con sus posibles estados. Cubrir sólo dos casos (la expresión se cumple o no se cumple) puede ocultarnos información, particularmente en el caso de expresiones que incluyan operadores OR.

\n\n

Para finalizar

\n\n

El code coverage es una medida que no debería obsesionarnos. Si hacemos tests, el code coverage crecerá. Y si hacemos TDD, el cede coverage vendrá por si solo.

\n\n

Pero sí es recomendable utilizarlo como herramienta cuando estamos refactorizando. Bien utilizada, nos indica qué codigo necesita ser cubierto y descrito con tests.

\n\n\n

Testeando lo impredecible

\n\n

¿Cómo testear lo que no podemos predecir? En muchos sentidos los tests se basan en que el comportamiento del código es predecible: si hacemos ciertas operaciones con ciertos datos podemos esperar ciertos resultados y no otros. Pero esto no siempre se cumple, a veces tenemos que testear algo que no sabemos qué será.

\n\n

Generando contraseñas para humanos

\n\n

Hace algunos años, cuando trabajaba en un colegio, tenía que crear cuentas para los usuarios de varias aplicaciones. Una queja habitual era la dificultad de recordar o simplemente transcribir las contraseñas que se asignaban y todo el mundo quería cambiarlas por alguna más fácil de memorizar. Y por una buena razón.

\n\n

Para explicarla, desempolvaré aquí alguno de mis libros de Psicología General, en concreto el artículo clásico de George A. Miller sobre el mágico número siete (más o menos dos.

\n\n

Resumiendo mucho: nuestro cerebro puede procesar una media de siete unidades de información a la vez. Por ejemplo, para una persona adulta es posible recordar seis ó siete letras al azar sin cometer errores. Si aumentamos el número de letras por encima de ese límite, el recuerdo empeora.

\n\n

Ahora bien, si podemos agrupar esas letras en sílabas de modo que se mantenga el límite de seis ó siete unidades de información, también llamadas chunks, podríamos llegar a recordar 21 letras suponiendo sílabas de tres letras. Y si esas letras pueden formar palabras, son más memorables todavía.

\n\n

Por ejemplo, cuando memorizamos números de teléfono lo hacemos organizándolos en grupos de dos ó tres. De este modo, un número que tiene nueve dígitos, se reduce a tres unidades de información, mucho más fácil de recordar.

\n\n

Así que, volviendo al caso de las contraseñas, en lugar de tener que recordar una serie de más de ocho símbolos al azar, lo ideal sería poder agruparlos en algún tipo de unidad de orden superior cuyo recuerdo sea más económico cognitivamente hablando.

\n\n

Una palabra es muchísimo más fácil de recordar pues agrupa esos ocho o más caracteres es una única unidad, sin embargo la descartamos como contraseña porque tiene el problema de ser fácil de adivinar.

\n\n

En cambio, podemos combinar letras para formar palabras que sin tener significado sean pronunciables (balotri, carbinacho…), lo que permite a nuestro cerebro tratarlas como una unidad. Al no estar en un diccionario son más difíciles de adivinar que las palabras reales.

\n\n

Así que en su día, investigué un poco y encontré algunos generadores de contraseñas legibles o pronunciables por humanos que se basaban en este razonamiento.

\n\n

La idea básica es que en lugar de formar las contraseñas mezclando caracteres al azar, lo que hacemos es mezclar sílabas, creando palabras posibles en el idioma aunque no tengan ningún significado. De este modo las contraseñas mantienen un compromiso aceptable entre ser fáciles de recordar pero difíciles de adivinar.

\n\n

Con esta idea en la cabeza escribí un generador de contraseñas legibles que me resultó bastante útil durante algunos años. Recientemente lo hemos rescatado, con algunas modificaciones, para introducirlo de tapadillo en un proyecto del trabajo en el que justamente necesitábamos proporcionar credenciales a un conjunto de usuarios.

\n\n

El único problema es que, de vez en cuando, aparece alguna contraseña que recuerda vagamente a palabras malsonantes, pero qué le vamos a hacer.

\n\n

En cualquier caso, nuestro Readable Password Generator plantea unos cuantos problemas interesantes y en este artículo vamos a reescribirlo usando TDD para aprender a resolverlos.

\n\n

Pero antes, un poco más de paliza teórica para acabar de situarnos… porque sigues ahí, ¿verdad?

\n\n

Determinismo y predictibilidad

\n\n

Cuando un algoritmo ofrece unos resultados que podemos predecir a partir de los datos que le proporcionamos decimos que es determinista. Por ejemplo, si multiplicamos 15 * 3 el resultado será siempre 45. Como vimos en un artículo anterior, si al repetir el algoritmo con los mismos datos siempre obtenemos los mismos resultados, también decimos que es idempotente.

\n\n

Hay operaciones, sin embargo, que no tienen el mismo resultado cada vez. Por ejemplo: si consultamos la hora del sistema la lectura será siempre diferente, asumiendo que la consulta se hace con la precisión necesaria. Por tanto, si un algoritmo depende de la hora del sistema no podríamos predecir su resultado a no ser que supiésemos exactamente el momento en que se consulta.

\n\n

Una manera más formal de expresar esto mismo es decir que el algoritmo en cuestión depende de un estado global, como puede ser el tiempo transcurrido en el mundo, o al menos, en el equipo sobre el que se ejecuta.

\n\n

La hora del sistema no es de naturaleza aleatoria, pero normalmente no podemos saber qué valor vamos a encontrar cuando la consultemos. Estaremos en condiciones de conocer algunas de sus características, por ejemplo que ese valor siempre será mayor que el que tenía al iniciarse nuestro algoritmo, pero poco más.

\n\n

Otro ejemplo es el siguiente. Si nuestro algoritmo necesita valores al azar necesitamos recurrir a un generador de números aleatorios, o al menos pseudoaleatorios. Un ordenador es una máquina determinista pero tenemos algoritmos capaces de generar valores que sin ser estrictamente aleatorios son suficientemente difíciles de predecir como para funcionar como tales.

\n\n

Así que, cuando tenemos que escribir código que necesita tratar con el tiempo o el azar, ¿cómo podremos testearlo?

\n\n

Para responder a esta pregunta, tendremos que recurrir al principio de única responsabilidad, descargando a nuestro generador de contraseñas de la tarea de obtener valores aleatorios.

\n\n

Además, introduciremos una metodología de test basada en propiedades, como la expuesta en esta charla de Pedro Santos, que nos permita testear aquello que no podemos predecir, pero que podemos describir.

\n\n

Vamos allá.

\n\n

A ver qué sale

\n\n

El primer problema a la hora de testear un método que devuelve valores generados de forma aleatoria es justamente no tener ni idea de lo que va a salir.

\n\n

Una posibilidad es centrarnos en propiedades que describan el resultado que esperamos, las cuales podríamos enunciar como reglas de negocio de nuestro generador de contraseñas.

\n\n

Por ejemplo:

\n\n

La contraseña es de tipo string\n
Tiene una longitud de al menos 6 caracteres (este límite es arbitrario)
Es un string de al menos 6 símbolos al azar
Es memorizable para humanos
Debe incluir al menos un número
Debe incluir al menos un símbolo no alfanumérico

\n\n

Así que vayamos paso a paso:

\n\n

 1 namespace Tests\\TalkingBit\\Readable;\n 2 \n 3 use PHPUnit\\Framework\\TestCase;\n 4 use TalkingBit\\Readable\\PasswordGenerator;\n 5 \n 6 class PasswordGeneratorTest extends TestCase\n 7 {\n 8 \n 9     public function testItGeneratesAStringPassword(): void\n10     {\n11         $generator = new PasswordGenerator();\n12         $password = $generator->generate();\n13         $this->assertInternalType('string', $password);\n14     }\n15 }\n

\n\n\n\n

Esto nos permite crear una primera implementación simple para poder empezar:

\n\n

1 class PasswordGenerator\n2 {\n3 \n4     public function generate(): string\n5     {\n6         return \"\";\n7     }\n8 }\n

\n\n\n\n

El return type en generate hace que el test sea redundante porque nos obliga a devolver el tipo correcto sí o sí. Por tanto lo podremos eliminar aunque nos ha permitido escribir la primera implementación.

\n\n

Lo que hay en un nombre

\n\n

Además de tener un tipo string, esperamos que tenga una longitud mínima. Este sería nuestro nuevo test:

\n\n

1     public function testItGeneratesAStringWithAMinimumLengthOfSixCharacters()\n2     {\n3         $generator = new PasswordGenerator();\n4         $password = $generator->generate();\n5         $this->assertGreaterThanOrEqual(6, strlen($password));\n6     }\n

\n\n\n\n

De nuevo, podemos hacer una implementación mínima e inflexible:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class PasswordGenerator\n 4 {\n 5 \n 6     public function generate(): string\n 7     {\n 8         return \"abcdef\";\n 9     }\n10 }\n

\n\n\n\n

Esto nos sitúa en verde de nuevo. Podemos echar un vistazo a lo que tenemos para ver si es posible hacer algún refactor, antes de seguir avanzando.

\n\n

En el código de producción de momento no tenemos nada reseñable, pero en el test tenemos un número mágico. La longitud mínima de la cadena está incrustada en el código y en el nombre del test. Ambas cosas son malas, Si en el futuro esta regla cambia tendremos que cambiar cosas en varios sitios. Es mejor hacerlo ahora.

\n\n

Empecemos con el nombre del test, haciéndolo más genérico:

\n\n

1     public function testItGeneratesAStringWithAMinimumLength()\n2     {\n3         $generator = new PasswordGenerator();\n4         $password = $generator->generate();\n5         $this->assertGreaterThanOrEqual(6, strlen($password));\n6     }\n

\n\n\n\n

Eso está mejor, ahora el nombre del test no está ligado a una longitud concreta, sino a un concepto más abstracto de longitud mínima.

\n\n

Y luego tendríamos que sustituir el número mágico por una constante o una variable para darle nombre y poder cambiarlo con facilidad llegado el caso. Esta regla debería residir en un único lugar, por lo que la opción más obvia es que esté en el propio generador de contraseñas. Como no se nos pide que sea configurable ni modificable puede ser una constante y la vamos a hacer pública para tener la opción de recurrir a ella en diferentes momentos.

\n\n

1 class PasswordGenerator\n2 {\n3     public const MINIMUM_LENGTH = 6;\n4 \n5     public function generate(): string\n6     {\n7         return \"abcdef\";\n8     }\n9 }\n

\n\n\n\n

Y ahora podríamos cambiar el test conforme a lo anterior:

\n\n

1     public function testItGeneratesAStringWithAMinimumLength()\n2     {\n3         $generator = new PasswordGenerator();\n4         $password = $generator->generate();\n5         $this->assertGreaterThanOrEqual(PasswordGenerator::MINIMUM_LENGTH, strlen($p\\\n6 assword));\n7     }\n

\n\n\n\n

Por el momento no tenemos gran cosa ya que nuestra implementación realmente no hace nada, aunque sí cumpla las primeras especificaciones. El problema es que ninguna de ellas nos fuerza a implementar algo más.

\n\n

Introduciendo el azar

\n\n

La siguiente especificación nos pide un string de al menos seis símbolos al azar. No nos especifica qué tipo de símbolos, aunque podemos hacer algunas suposiciones con cierto fundamento como usar números, letras y algunos otros símbolos.

\n\n

¿Qué es aleatorio?

\n\n

Pero esta especificación es un poco difusa. En realidad cualquier cadena de caracteres sería válida dado que cualquier cadena puede haber sido generada al azar. Podemos suponer que se refiere a secuencias que no formen una palabra conocida pero, ¿cómo demonios podemos testear eso de una manera eficaz?

\n\n

En realidad para hacerlo bien deberíamos realizar un análisis estadístico basado en el siguiente razonamiento:

\n\n

Si tenemos un conjunto finito de n símbolos, la posibilidad de extraer uno cualquiera de ellos del conjunto es 1/n. Por tanto, si repetimos la extracción (con reposición) un gran número de veces (varios cientos, al menos), obtendremos una frecuencia para cada símbolo que será 1/n o un valor muy próximo. Cuanto mayor sea el número de veces que repetimos el experimento, más aproximado será el resultado.

\n\n

Extrayendo la aleatoridad de nuestra clase

\n\n

Ahora bien este test no sólo es poco práctico para nuestro caso, sino que además lo que realmente testea es un hipotético generador aleatorio de símbolos, el cual podría ser utilizado por nuestro generador de contraseñas. Este se encargará de pedir al generador aleatorio los símbolos que vaya necesitando y componer la contraseña con ellos.

\n\n

De momento no vamos a crear el generador aleatorio, pero sí crearemos una interfaz para poder utilizar un test double suyo.

\n\n

1 namespace TalkingBit\\Readable;\n2 \n3 interface RandomSymbolGenerator\n4 {\n5     public function generate();\n6 }\n

\n\n\n\n

En resumen, nuestro generador de contraseñas utilizará un generador aleatorio de símbolos que le pasaremos como dependencia.

\n\n

Esto tiene una gran ventaja porque para el test podemos tener un doble del generador aleatorio que no sea aleatorio. De este modo, las contraseñas generadas serán predecibles y podemos testear su construcción.

\n\n

Para empezar seguimos necesitando un test que nos fuerce a implementar algo en el código de producción.

\n\n

Una primera idea que podemos experimentar es la siguiente: Podemos hacer que nuestro generador entregue una secuencia concreta de símbolos y testear que la contraseña devuelta reproduzca esa misma secuencia.

\n\n

De este modo, probaremos que el generador de contraseñas utiliza al colaborador.

\n\n

 1     public function testItGeneratesAPasswordUsingSymbolsPickedfromRandomGeneartor()\n 2     {\n 3         $randomProphecy = $this->prophesize(RandomSymbolGenerator::class);\n 4         $randomProphecy->generate()->willReturn('1', '2', '3', '4', '5', '6');\n 5         $generator = new PasswordGenerator($randomProphecy->reveal());\n 6         \n 7         $password = $generator->generate();\n 8         \n 9         $this->assertEquals('123456', $password);\n10     }\n

\n\n\n\n

Como es obvio, el test no pasará y nos toca implementar algo:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class PasswordGenerator\n 4 {\n 5     public const MINIMUM_LENGTH = 6;\n 6     \n 7     /** @var RandomSymbolGenerator */\n 8     private $RandomSymbolGenerator;\n 9 \n10     public function __construct(RandomSymbolGenerator $RandomSymbolGenerator)\n11     {\n12         $this->RandomSymbolGenerator = $RandomSymbolGenerator;\n13     }\n14 \n15     public function generate(): string\n16     {\n17         $password = '';\n18         for ($item = 0; $item < self::MINIMUM_LENGTH; $item++) {\n19             $password .= $this->RandomSymbolGenerator->generate();\n20         }\n21         return $password;\n22     }\n23 }\n

\n\n\n\n

Esta implementación nos permite pasar el test y cumplir la especificación.

\n\n

Generando un password legible

\n\n

El tema de la aleatoridad ha abierto la necesidad de crear un colaborador para nuestro generador de contraseñas: un generador aleatorio que nos entregue un valor cada vez que lo llamamos.

\n\n

De momento hemos creado un doble para usarlo en el test y le hemos fijado la secuencia en la que entrega valores. De este modo, hemos podido testear que el generador de contraseñas lo utiliza y que lo llama las veces necesarias.

\n\n

Lo bueno, además, es que hemos logrado el acoplamiento mínimo posible del test a la implementación pues no hemos fijado expectativas sobre la forma en que el colaborador es usado.

\n\n

Así que nos movemos a la siguiente especificación y nos dice que la contraseña ha de ser memorizable. En este caso, asumimos que queremos una contraseña construida uniendo sílabas escogidas al azar.

\n\n

Nuestra interfaz RandomSymbolGenerator entrega un string cada vez que llamamos al método generate. Así que podríamos crear una implementación que entregue una sílaba escogida al azar cada vez.

\n\n

Obviamente, si queremos desarrollar esta implementación mediante TDD nos volvemos a topar con el problema del testeo no determinista. En el caso anterior lo hemos solucionado extrayendo la parte aleatoria, ¿podemos hacerlo ahora también?

\n\n

Añadiendo otro nivel de indirección

\n\n

Hemos dicho que la responsabilidad de obtener símbolos al azar debería estar fuera del generador de contraseñas. Ahora queremos crear una implementación concreta de ese generador aleatorio de símbolos que nos devuelva sílabas.

\n\n

Y, de nuevo, podemos pensar en dos responsabilidades: la generación o gestión de los símbolos que vamos a utilizar y la generación de un valor aleatorio que nos permita elegir uno concreto.

\n\n

Pero esta delegación no puede producirse indefinidamente. Separaremos la lógica en dos clases, una es el RandomSymbolGenerator que entrega un símbolo de tipo string (una letra, una sílaba, un número, un bloque cualquiera de símbolos, etc.), y la otra es un RandomnessEngine que entregará un valor entero aleatorio que nos permitirá elegir un símbolo al azar de entre todos los posibles en el RandomSymbolGenerator concreto.

\n\n

Así que vamos con cada uno de ellos.

\n\n

Un generador de sílabas

\n\n

En español, una sílaba es un conjunto de letras que cumple las siguientes reglas:

\n\n

Tiene al menos una vocal
Si tiene más vocales, han de formar un diptongo
Puede comenzar, o no, con una consonante
O por un grupo de consonantes del conjunto válido
Puede terminar, o no, con una consonante del conjunto válido

\n\n

Estas especificaciones son bastante claras, así que vamos a convertirlas en tests. El más básico de todos es el que toda sílaba tiene, al menos, una vocal.

\n\n

 1 namespace Tests\\TalkingBit\\Readable;\n 2 \n 3 use TalkingBit\\Readable\\RandomSyllableGenerator;\n 4 use PHPUnit\\Framework\\TestCase;\n 5 \n 6 class RandomSyllableGeneratorTest extends TestCase\n 7 {\n 8 \n 9     public function testSyllableHasOneVocal()\n10     {\n11         $generator = new RandomSyllableGenerator();\n12         $syllable = $generator->generate();\n13         $this->assertRegExp('/[aeiou]/', $syllable);\n14     }\n15 }\n

\n\n\n\n

Comencemos por una implementación mínima para pasar el test:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class RandomSyllableGenerator implements RandomSymbolGenerator\n 4 {\n 5 \n 6     public function generate(): string\n 7     {\n 8         return 'a';\n 9     }\n10 }\n

\n\n\n\n

El siguiente requisito es que si hay más de una vocal, deben formar diptongo:

\n\n

Esto es algo más largo de expresar:

\n\n

1    public function testWhenTwoVowelsTheyMustFormDiphthong()\n2     {\n3         $generator = new RandomSyllableGenerator();\n4         $syllable = $generator->generate();\n5         $this->assertRegExp('/ai|au|ei|eu|ia|ie|io|iu|oi|ou|ua|ue|ui|uo/', $syllable\\\n6 );\n7     }\n8 }\n

\n\n\n

Por tanto, empezamos a implementar y llegamos a esta primera solución preliminar, que consiste en escoger una entre varias opciones de cada tipo:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class RandomSyllableGenerator implements RandomSymbolGenerator\n 4 {\n 5     private const VOWELS = ['a', 'e', 'i', 'o', 'u'];\n 6     private const DIPHTHONGS = [\n 7         'ai',\n 8         'au',\n 9         'ei',\n10         'eu',\n11         'ia',\n12         'ie',\n13         'iu',\n14         'oi',\n15         'ou',\n16         'ua',\n17         'ue',\n18         'ui',\n19         'uo'\n20     ];\n21     public function generate(): string\n22     {\n23         return self::DIPHTHONGS[1];\n24     }\n25 }\n

\n\n\n\n

Pero esta solución no es satisfactoria. Tal como queda reflejada ahora no estamos usando las vocales y, sin embargo, el test pasa igualmente.

\n\n

Parece más prometedor introducir un nuevo concepto llamado grupo vocálico, que englobe vocales únicas y diptongos. Eso implica que unimos las dos primeras especificaciones en una:

\n\n

Una sílaba debe tener siempre una vocal o dos que formen un diptongo.

\n\n

Existen 14 diptongos en español y, junto a las cinco vocales, dan un total de 19 grupos vocálicos que vamos a admitir en nuestro generador, que numerados como zero indexed nos da los extremos 0 y 18. Hemos decidido excluir los triptongos, para no liarlo mucho más.

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class RandomSyllableGenerator implements RandomSymbolGenerator\n 4 {\n 5     private const VOWEL_GROUP = [\n 6         'a', 'e', 'i', 'o', 'u',\n 7         'ai', 'au',\n 8         'ei', 'eu',\n 9         'ia', 'ie', 'io', 'iu',\n10         'oi', 'ou',\n11         'ua', 'ue', 'ui', 'uo'\n12     ];\n13     public function generate(): string\n14     {\n15         return self::VOWEL_GROUP[1];\n16     }\n17 }\n

\n\n\n\n

La nueva implementación hace fallar el segundo test y eso es una buena noticia porque nos obliga a pensar una implementación más general.

\n\n

Nuestro problema ahora es que todavía estamos en una implementación inflexible en la que siempre elegimos el mismo grupo vocálico, así que tenemos que encontrar una forma de seleccionarlo. Para eso necesitamos introducir un RandomnessEngine que lo escoja al azar.

\n\n

¡Ah! Pero estamos en test, necesitamos poder predeterminar qué elemento va a seleccionar nuestro RandomnessEngine. Así que vamos a crear un doble a partir de su interfaz.

\n\n

1 namespace TalkingBit\\Readable;\n2 \n3 interface RandomnessEngine\n4 {\n5     public function pickIntegerBetween(int $min, int $max): int;\n6 }\n

\n\n\n\n

Ya tenemos esta interfaz, suficiente para generar nuestro test double.

\n\n

Ahora modificaremos nuestros tests para forzar que RandomSyllableGenerator lo utilice. Empecemos por el que está fallando:

\n\n

1     public function testWhenTwoVowelsTheyMustFormDiphthong()\n2     {\n3         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n4         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(18);\n5         $generator = new RandomSyllableGenerator($engineProphecy->reveal());\n6         $syllable = $generator->generate();\n7         $this->assertRegExp('/ai|au|ei|eu|ia|ie|io|iu|oi|ou|ua|ue|ui|uo/', $syllable\\\n8 );\n9     }\n

\n\n\n\n

De momento, seguirá fallando porque no hemos implementado nada. Así que vamos a hacerlo pasar:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class RandomSyllableGenerator implements RandomSymbolGenerator\n 4 {\n 5     private const VOWEL_GROUP = [\n 6         'a', 'e', 'i', 'o', 'u',\n 7         'ai', 'au',\n 8         'ei', 'eu',\n 9         'ia', 'ie', 'io', 'iu',\n10         'oi', 'ou',\n11         'ua', 'ue', 'ui', 'uo'\n12     ];\n13     \n14     /** @var RandomnessEngine */\n15     private $RandomnessEngine;\n16 \n17     public function __construct(RandomnessEngine $RandomnessEngine)\n18     {\n19         $this->RandomnessEngine = $RandomnessEngine;\n20     }\n21 \n22     public function generate(): string\n23     {\n24         $pick = $this->RandomnessEngine->pickIntegerBetween(0, count(self::VOWEL_GRO\\\n25 UP) - 1);\n26 \n27         return self::VOWEL_GROUP[$pick];\n28     }\n29 }\n

\n\n\n\n

El segundo test ahora pasa, pero la nueva implementación nos obliga a cambiar el primero, que quedaría así:

\n\n

1     public function testSyllableHasOneVowel()\n2     {\n3         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n4         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(0);\n5         $generator = new RandomSyllableGenerator($engineProphecy->reveal());\n6         $syllable = $generator->generate();\n7         $this->assertRegExp('/[aeiou]/', $syllable);\n8     }\n

\n\n\n\n

Con este cambio, hemos conseguido implementar el grupo vocálico obligatorio en cada sílaba, testeando tanto los casos en que se genera una vocal única como los que se genera un diptongo.

\n\n

Y ahora que tenemos los tests en verde, es momento de refactorizar. Entre otras cosas porque nuestros tests no son buenos.

\n\n

Veamos: nuestros tests se basan en dos especificaciones que ahora hemos resumido en una sola. Por lo tanto, debería bastarnos con un único test que compruebe si el grupo vocálico es válido ya que podemos asumir que el RandonEngine, que estamos doblando, siempre nos va a permitir escoger un grupo válido de las opciones disponibles.

\n\n

Por tanto, unificamos los tests en uno sólo, y aprovechamos para dejar el código un poco más limpio:

\n\n

 1 namespace Tests\\TalkingBit\\Readable;\n 2 \n 3 use PHPUnit\\Framework\\TestCase;\n 4 use TalkingBit\\Readable\\RandomnessEngine;\n 5 use TalkingBit\\Readable\\RandomSyllableGenerator;\n 6 \n 7 class RandomSyllableGeneratorTest extends TestCase\n 8 {\n 9 \n10     const VOWEL_GROUP_PATTERN = '/[aeiou]|ai|au|ei|eu|ia|ie|io|iu|oi|ou|ua|ue|ui|uo/\\\n11 ';\n12 \n13     public function testASyllableHasOneVowelGroup()\n14     {\n15         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n16         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(4);\n17         $generator = new RandomSyllableGenerator($engineProphecy->reveal());\n18         $this->assertValidVowelGroup($generator->generate());\n19     }\n20     \n21     public function assertValidVowelGroup(string $syllable): void\n22     {\n23         $this->assertRegExp(self::VOWEL_GROUP_PATTERN, $syllable);\n24     }\n25 }\n

\n\n\n\n

Programando el mock de `RandomnessEngine`\n

\n\n

Nos queda un punto problemático: ¿qué valor debe retornar el mock de RandomnessEngine?

\n\n

En el test hemos puesto que devuelva 4, por ningún motivo especial. Podemos asumir que un RandomnessEngine devolverá siempre valores entre los límites que le indicamos, así que 4 es un valor tan bueno como cualquier otro entre 0 y 18.

\n\n

En realidad, lo que nos preocupa aquí es que RandomSyllableGenerator llame al RandomnessEngine con los valores correctos.

\n\n

Añadiendo consonantes al principio de la sílaba

\n\n

En nuestras especificaciones tenemos que las sílabas pueden comenzar, o no, por un grupo consonántico. En realidad, ocurre algo parecido al grupo vocálico. Podemos simplemente asumir que los valores válidos son el conjunto de las consonantes y el conjunto de los grupos de consonantes (por ejemplo, br- o tr-) que son válidos en español.

\n\n

En total, tenemos 33 opciones, a las que hay que sumar la posibilidad de que la sílaba no comience por consonante, lo que daría un total de 34 posibilidades.

\n\n

En último término podemos seguir la misma estrategia que usamos con las vocales, con la salvedad de que no es obligatorio que la sílaba comience por consonante. Como siempre, necesitamos enunciarlo en forma de test.

\n\n

En esta ocasión el salto será un poco más grande de lo habitual, de modo que aquí va todo el test case, bastante arreglado:

\n\n

 1 namespace Tests\\TalkingBit\\Readable;\n 2 \n 3 use PHPUnit\\Framework\\TestCase;\n 4 use TalkingBit\\Readable\\RandomnessEngine;\n 5 use TalkingBit\\Readable\\RandomSyllableGenerator;\n 6 \n 7 class RandomSyllableGeneratorTest extends TestCase\n 8 {\n 9 \n10     const VOWEL_GROUP_PATTERN = '[aeiou]|ai|au|ei|eu|ia|ie|io|iu|oi|ou|ua|ue|ui|uo';\n11     const CONSONANT_GROUP_PATTERN = '[^aeiou]|bl|br|ch|cl|cr|fl|fr|ll|pr|pl|tr';\n12 \n13     public function testASyllableHasOneVowelGroup()\n14     {\n15         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n16         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(4);\n17         $engineProphecy->pickIntegerBetween(0, 33)->willReturn(0);\n18         $generator = new RandomSyllableGenerator($engineProphecy->reveal());\n19         $this->assertValidVowelGroup($generator->generate());\n20     }\n21 \n22     public function testASyllableCanStartWithOneConsonantGroup()\n23     {\n24         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n25         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(0);\n26         $engineProphecy->pickIntegerBetween(0, 33)->willReturn(0);\n27         $generator = new RandomSyllableGenerator($engineProphecy->reveal());\n28         $this->assertStartsWithConsonantGroup($generator->generate());\n29     }\n30 \n31     public function assertValidVowelGroup(string $syllable): void\n32     {\n33         $this->assertRegExp(sprintf('/%s/', self::VOWEL_GROUP_PATTERN), $syllable);\n34     }\n35 \n36     private function assertStartsWithConsonantGroup(string $syllable): void\n37     {\n38         $pattern = sprintf('/^(%s)?/', self::CONSONANT_GROUP_PATTERN, self::VOWEL_GR\\\n39 OUP_PATTERN);\n40         $this->assertRegExp($pattern, $syllable);\n41     }\n42 }\n

\n\n\n

En cuanto a la implementación, la sílaba que no empieza consonante puede puede simularse incluyendo un “grupo vacío”, aunque hay otras posibilidades bastante obvias.

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class RandomSyllableGenerator implements RandomSymbolGenerator\n 4 {\n 5     private const VOWEL_GROUP = [\n 6         'a',\n 7         'e',\n 8         'i',\n 9         'o',\n10         'u',\n11         'ai',\n12         'au',\n13         'ei',\n14         'eu',\n15         'ia',\n16         'ie',\n17         'io',\n18         'iu',\n19         'oi',\n20         'ou',\n21         'ua',\n22         'ue',\n23         'ui',\n24         'uo'\n25     ];\n26 \n27     private const CONSONANT_GROUP = [\n28         'b',\n29         'c',\n30         'd',\n31         'f',\n32         'g',\n33         'h',\n34         'j',\n35         'k',\n36         'l',\n37         'm',\n38         'n',\n39         'ñ',\n40         'p',\n41         'q',\n42         'r',\n43         's',\n44         't',\n45         'v',\n46         'w',\n47         'x',\n48         'y',\n49         'z',\n50         'bl',\n51         'br',\n52         'ch',\n53         'cl',\n54         'cr',\n55         'fl',\n56         'fr',\n57         'll',\n58         'pr',\n59         'pl',\n60         'tr',\n61         ''\n62     ];\n63 \n64     /** @var RandomnessEngine */\n65     private $RandomnessEngine;\n66 \n67     public function __construct(RandomnessEngine $RandomnessEngine)\n68     {\n69         $this->RandomnessEngine = $RandomnessEngine;\n70     }\n71 \n72     public function generate(): string\n73     {\n74         return $this->pickAConsonant() . $this->pickAVowel();\n75     }\n76 \n77     private function pickAVowel(): string\n78     {\n79         $pick = $this->RandomnessEngine->pickIntegerBetween(0, count(self::VOWEL_GRO\\\n80 UP) - 1);\n81 \n82         return self::VOWEL_GROUP[$pick];\n83     }\n84     \n85     private function pickAConsonant(): string\n86     {\n87         $pick = $this->RandomnessEngine->pickIntegerBetween(0, count(self::CONSONANT\\\n88 _GROUP) - 1);\n89 \n90         return self::CONSONANT_GROUP[$pick];\n91     }\n92 }\n

\n\n\n\n

Y ahora, sílabas terminadas en consonante

\n\n

Para terminar la generación de sílabas, seguiremos un procedimiento parecido. En este caso sólo hay cinco terminaciones posibles (n, l, s, r, d), además de la posibilidad de que la sílaba acabe en consonante.

\n\n

En principio, este será el test con el que probarlo:

\n\n

 1     public function testASyllableCanEndWithAConsonant()\n 2     {\n 3         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n 4         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(0);\n 5         $engineProphecy->pickIntegerBetween(0, 33)->willReturn(0);\n 6         $engineProphecy->pickIntegerBetween(0, 5)->willReturn(0);        \n 7         $generator = new RandomSyllableSymbolGenerator($engineProphecy->reveal());\n 8         \n 9         $this->assertRegExp('/[nlsrd]?$/', $generator->generate());\n10     }\n

\n\n\n\n

Y esta la implementación que lo cumpla:

\n\n

  1 namespace TalkingBit\\Readable;\n  2 \n  3 class RandomSyllableSymbolGenerator implements RandomSymbolGenerator\n  4 {\n  5     private const VOWEL_GROUP = [\n  6         'a',\n  7         'e',\n  8         'i',\n  9         'o',\n 10         'u',\n 11         'ai',\n 12         'au',\n 13         'ei',\n 14         'eu',\n 15         'ia',\n 16         'ie',\n 17         'io',\n 18         'iu',\n 19         'oi',\n 20         'ou',\n 21         'ua',\n 22         'ue',\n 23         'ui',\n 24         'uo'\n 25     ];\n 26 \n 27     private const CONSONANT_GROUP = [\n 28         'b',\n 29         'c',\n 30         'd',\n 31         'f',\n 32         'g',\n 33         'h',\n 34         'j',\n 35         'k',\n 36         'l',\n 37         'm',\n 38         'n',\n 39         'ñ',\n 40         'p',\n 41         'q',\n 42         'r',\n 43         's',\n 44         't',\n 45         'v',\n 46         'w',\n 47         'x',\n 48         'y',\n 49         'z',\n 50         'bl',\n 51         'br',\n 52         'ch',\n 53         'cl',\n 54         'cr',\n 55         'fl',\n 56         'fr',\n 57         'll',\n 58         'pr',\n 59         'pl',\n 60         'tr',\n 61         ''\n 62     ];\n 63 \n 64     private const ENDING_CONSONANT = ['n', 'l', 's', 'r', 'd', ''];\n 65 \n 66     /** @var RandomnessEngine */\n 67     private $randomEngine;\n 68 \n 69     public function __construct(RandomnessEngine $randomEngine)\n 70     {\n 71         $this->randomEngine = $randomEngine;\n 72     }\n 73 \n 74     public function generate(): string\n 75     {\n 76         return $this->pickAConsonant()\n 77             . $this->pickAVowel()\n 78             . $this->pickEndingConsonant();\n 79     }\n 80 \n 81     private function pickAVowel(): string\n 82     {\n 83         $pick = $this->randomEngine->pickIntegerBetween(0, count(self::VOWEL_GROUP) \\\n 84 - 1);\n 85 \n 86         return self::VOWEL_GROUP[$pick];\n 87     }\n 88 \n 89     private function pickAConsonant(): string\n 90     {\n 91         $pick = $this->randomEngine->pickIntegerBetween(0, count(self::CONSONANT_GRO\\\n 92 UP) - 1);\n 93 \n 94         return self::CONSONANT_GROUP[$pick];\n 95     }\n 96 \n 97     private function pickEndingConsonant(): string\n 98     {\n 99         $pick = $this->randomEngine->pickIntegerBetween(0, count(self::ENDING_CONSON\\\n100 ANT) -1);\n101 \n102         return self::ENDING_CONSONANT[$pick];\n103     }\n104 }\n

\n\n\n\n

Ahora que tenemos todos los tests pasando en verde voy a refactorizar los tests, dado que hay unas repeticiones bastante manifiestas:

\n\n

 1 namespace Tests\\TalkingBit\\Readable;\n 2 \n 3 use PHPUnit\\Framework\\TestCase;\n 4 use TalkingBit\\Readable\\RandomnessEngine;\n 5 use TalkingBit\\Readable\\RandomSyllableSymbolGenerator;\n 6 \n 7 class RandomSyllableGeneratorTest extends TestCase\n 8 {\n 9 \n10     const VOWEL_GROUP_PATTERN = '[aeiou]|ai|au|ei|eu|ia|ie|io|iu|oi|ou|ua|ue|ui|uo';\n11     const CONSONANT_GROUP_PATTERN = '[^aeiou]|bl|br|ch|cl|cr|fl|fr|ll|pr|pl|tr';\n12 \n13     public function testASyllableHasOneVowelGroup()\n14     {\n15         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n16         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(0);\n17         $engineProphecy->pickIntegerBetween(0, 33)->willReturn(0);\n18         $engineProphecy->pickIntegerBetween(0, 5)->willReturn(0);\n19         $generator = new RandomSyllableSymbolGenerator($engineProphecy->reveal());\n20         $this->assertValidVowelGroup($generator->generate());\n21     }\n22 \n23     public function testASyllableCanStartWithOneConsonantGroup()\n24     {\n25         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n26         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(0);\n27         $engineProphecy->pickIntegerBetween(0, 33)->willReturn(0);\n28         $engineProphecy->pickIntegerBetween(0, 5)->willReturn(0);\n29         $generator = new RandomSyllableSymbolGenerator($engineProphecy->reveal());\n30         $this->assertStartsWithConsonantGroup($generator->generate());\n31     }\n32 \n33     public function testASyllableCanEndWithAConsonant()\n34     {\n35         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n36         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(0);\n37         $engineProphecy->pickIntegerBetween(0, 33)->willReturn(0);\n38         $engineProphecy->pickIntegerBetween(0, 5)->willReturn(0);\n39         $generator = new RandomSyllableSymbolGenerator($engineProphecy->reveal());\n40         $this->assertRegExp('/[nlsrd]$/', $generator->generate());\n41     }\n42 \n43     public function assertValidVowelGroup(string $syllable): void\n44     {\n45         $this->assertRegExp(sprintf('/%s/', self::VOWEL_GROUP_PATTERN), $syllable);\n46     }\n47 \n48     private function assertStartsWithConsonantGroup(string $syllable): void\n49     {\n50         $pattern = sprintf('/^(%s)%s/', self::CONSONANT_GROUP_PATTERN, self::VOWEL_G\\\n51 ROUP_PATTERN);\n52         $this->assertRegExp($pattern, $syllable);\n53     }\n54 }\n

\n\n\n\n

De forma que quedaría más o menos así:

\n\n

 1 namespace Tests\\TalkingBit\\Readable;\n 2 \n 3 use PHPUnit\\Framework\\TestCase;\n 4 use TalkingBit\\Readable\\RandomnessEngine;\n 5 use TalkingBit\\Readable\\RandomSyllableSymbolGenerator;\n 6 \n 7 class RandomSyllableGeneratorTest extends TestCase\n 8 {\n 9 \n10     const VOWEL_GROUP_PATTERN = '[aeiou]|ai|au|ei|eu|ia|ie|io|iu|oi|ou|ua|ue|ui|uo';\n11     const CONSONANT_GROUP_PATTERN = '[^aeiou]|bl|br|ch|cl|cr|fl|fr|ll|pr|pl|tr';\n12     const ENDING_CONSONANT = '[nlsrd]';\n13 \n14     private $randomSyllableSymbolGenerator;\n15 \n16     public function setUp()\n17     {\n18         $engineProphecy = $this->prophesize(RandomnessEngine::class);\n19         $engineProphecy->pickIntegerBetween(0, 18)->willReturn(0);\n20         $engineProphecy->pickIntegerBetween(0, 33)->willReturn(0);\n21         $engineProphecy->pickIntegerBetween(0, 5)->willReturn(0);\n22         $this->randomSyllableSymbolGenerator = new RandomSyllableSymbolGenerator($en\\\n23 gineProphecy->reveal());\n24     }\n25 \n26     public function testASyllableHasOneVowelGroup()\n27     {\n28         $syllable = $this->randomSyllableSymbolGenerator->generate();\n29         $this->assertValidVowelGroup($syllable);\n30     }\n31 \n32     public function testASyllableCanStartWithOneConsonantGroup()\n33     {\n34         $syllable = $this->randomSyllableSymbolGenerator->generate();\n35         $this->assertStartsWithConsonantGroup($syllable);\n36     }\n37 \n38     public function testASyllableCanEndWithAConsonant()\n39     {\n40         $syllable = $this->randomSyllableSymbolGenerator->generate();\n41         $this->assertEndsWithConsonant($syllable);\n42     }\n43 \n44     private function assertValidVowelGroup(string $syllable): void\n45     {\n46         $this->assertRegExp(sprintf('/%s/', self::VOWEL_GROUP_PATTERN), $syllable);\n47     }\n48 \n49     private function assertStartsWithConsonantGroup(string $syllable): void\n50     {\n51         $pattern = sprintf('/^(%s)?/', self::CONSONANT_GROUP_PATTERN, self::VOWEL_GR\\\n52 OUP_PATTERN);\n53         $this->assertRegExp($pattern, $syllable);\n54     }\n55 \n56 \n57     private function assertEndsWithConsonant(string $syllable): void\n58     {\n59         $pattern = sprintf('/(%s)?$/', self::ENDING_CONSONANT);\n60         $this->assertRegExp($pattern, $syllable);\n61     }\n62 }\n

\n\n\n\n

Testeando el azar

\n\n

Recapitulemos un poco:

\n\n

Empezamos creando un generador de contraseñas, hasta que nos vimos en la necesidad de separar responsabilidades: por un lado, el generador de la contraseña PasswordGenerator y, por otro, el generador de símbolos que será del tipo RandomSymbolGenerator y que, para nuestro caso, es RandomSyllableSymbolGenerator.

\n\n

El generador de la contraseña se limita a concatenar símbolos al azar que obtiene del generador de símbolos. Como tal, el generador no tiene ningún conocimiento acerca de cómo genera su colaborador los símbolos, con tal de que cada vez que lo llame le entregue uno que pueda concatenar. En otras palabras: a PasswordGenerator sólo le importa que se cumpla el contrato o interfaz RandomSymbolGenerator.

\n\n

Por otra parte, al implementar un RamdomSymbolGenerator identificamos y decidimos separar dos responsabilidades: la composición del símbolo como tal, que de nuevo es concatenar una serie de piezas, y la aleatoriedad en la elección de estas piezas, que hemos extraído a un contrato o interfaz RandomnessEngine.

\n\n

Esto tiene unas cuantas ventajas:

\n\n

A lo hora de testear hemos conseguido aplazar el tener que enfrentarnos con el azar y el no determinismo, aunque ahora nos toca ponernos a ello.
Podremos elegir diversas estrategias para generar valores aleatorios, dependiendo de las necesidades que tengamos.

\n\n

Así que ahora vamos a construir nuestro RandomnessEngine con TDD.

\n\n

Testear el azar mediante propiedades

\n\n

En esencia, RandomnessEngine es un generador de números aleatorios. Como no sabemos qué número va a generar, no podemos hacer aserciones sobre los valores específicos que nos entrega. A cambio, podemos testear sobre propiedades que deberían cumplir:

\n\n

Ser números enteros
Ser mayores o iguales que un límite inferior
Ser menores o iguales que un límite superior

\n\n

Como RandomnessEngine es una interfaz vamos a crear una implementación de la misma, que yo voy a llamar SystemRandomnessEngine. Otra alternativa, sería convertir la interfaz en clase si es que preveemos que será la única implementación.

\n\n

Como ya sabemos, forzar un tipo de retorno hace que el test de tipo sea redundante, por lo que vamos directamente al primer requisito:

\n\n

 1 namespace Tests\\TalkingBit\\Readable;\n 2 \n 3 use TalkingBit\\Readable\\SystemRandomnessEngine;\n 4 use PHPUnit\\Framework\\TestCase;\n 5 \n 6 class SystemRandomnessEngineTest extends TestCase\n 7 {\n 8 \n 9     public function testGeneratesANUmberEqualOrGreaterThanAMinimum()\n10     {\n11         $randomEngine = new SystemRandomnessEngine();\n12         $this->assertGreaterThanOrEqual(0, $randomEngine->pickIntegerBetween(0, 0));\n13     }\n14 }\n

\n\n\n\n

Ejecutamos el test para verlo fallar y escribir el código necesario para que pase.

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class SystemRandomnessEngine implements RandomnessEngine\n 4 {\n 5 \n 6     public function pickIntegerBetween(int $minimum, int $maximum): int\n 7     {\n 8         return 10000;\n 9     }\n10 }\n

\n\n\n\n

El valor devuelto es arbitrario, pero no queremos que sea cero por una razón: en nuestro siguiente test vamos a comprobar el otro extremo del intervalo de números permitidos, por lo que devolvemos un número que nos permita fijar un máximo más pequeño y asegurarnos de escribir un test que falle.

\n\n

Como ya estamos en verde, escribimos otro test que nos fuerce a implementar la generación de números al azar:

\n\n

1     public function testGeneratesANumberEqualOrLessThanAMaximum()\n2     {\n3         $randomEngine = new SystemRandomnessEngine();\n4         $this->assertLessThanOrEqual(10, $randomEngine->pickIntegerBetween(10, 10));\n5     }\n

\n\n\n\n

En nuestro caso, no nos vamos a complicar mucho la vida, aceptando uno de los generadores incluidos en PHP, de modo que consigamos hacer pasar el test:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class SystemRandomnessEngine implements RandomnessEngine\n 4 {\n 5 \n 6     public function pickIntegerBetween(int $minimum, int $maximum): int\n 7     {\n 8         return random_int($minimum, $maximum);\n 9     }\n10 }\n

\n\n\n\n

Realmente es una implementación trivial, pero lo que intento mostrar aquí no es tanto cómo generar números aleatorios, sino cómo testear eso. Por otro lado, ahora tenemos una clase-servicio que nos proporciona números enteros al azar para cualquier uso que podamos darle.

\n\n

Así que toca regresar PasswordGenerator

\n\n

Probamos nuestro generador de constraseñas

\n\n

Ahora estamos en condiciones de montar PasswordGenerator y que nos proporcione contraseñas legibles por humanos.

\n\n

Veamos un ejemplo:

\n\n

 1 //playground.php\n 2 \n 3 namespace TalkingBit\\Readable;\n 4 \n 5 require_once '../vendor/autoload.php';\n 6 \n 7 $passwordGenerator = new PasswordGenerator(\n 8     new RandomSyllableSymbolGenerator(\n 9         new SystemRandomnessEngine()\n10     )\n11 );\n12 \n13 for ($count = 0; $count <= 10; $count++) {\n14     print $passwordGenerator->generate() . PHP_EOL;\n15 }\n

\n\n\n\n

Que genera lo siguiente:

\n\n

 1 reulculzienmoidzienwiol\n 2 buesjeinfrainfloteiltrau\n 3 algofeusyeirguiscras\n 4 buadbaurdollausbradluos\n 5 jilbleinmiedpruirmouquan\n 6 poidheisbeischuishilfli\n 7 jiaxialpaibiasguonfid\n 8 mioyainualyiodbradxaul\n 9 cluezierfrurreislluoslas\n10 meinproisriadsaudblaileil\n11 hiadbrauspriulgiadfoinxias\n

\n\n\n\n

Ciertamente, no son contraseñas muy legibles, pero es que son muy largas y las sílabas son complejas, superan con creces el límite de seis caracteres y al contener muchas sílabas trabadas se hacen complicadas de leer.

\n\n

Tenemos dos problemas aquí:

\n\n

La longitud de la contraseña medida en caracteres no es el mismo concepto que su medida en símbolos, ya que éstos pueden estar compuestos de varios caracteres cada uno. La especificación sigue siendo válida, pero el uso que hacemos de ella para contar el número de símbolos no lo es.
Por otro lado, tendríamos que manipular el azar para obtener sílabas menos complejas.

\n\n

Vamos a ello:

\n\n

Contraseñas más cortas con la misma especificación

\n\n

Un problema con la especificación original es que sólo pone un límite inferior al tamaño de las contraseñas generadas. Si se hubiera definido también un límite superior quizá no tuviésemos ese problema.

\n\n

Como hemos mencionado antes, el problema es que comenzamos trabajando con el concepto de contraseña como una sucesión de caracteres y hemos desarrollado una solución que lo define como una sucesión de sílabas y, en algunos momentos, hemos tomado como equivalentes sílabas o símbolos y caracteres individuales, de modo que hemos asumido que nuestro RamdomGenerator entrega caracteres. Si PHP tuviese un tipo de dato char quizá hubiésemos sido más conscientes de este problema.

\n\n

Pero bueno, tenemos tests y, en este caso, podemos refactorizar la solución por una equivalente que refleje mejor la diferencia de los conceptos:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 class PasswordGenerator\n 4 {\n 5     public const MINIMUM_LENGTH = 6;\n 6     /**\n 7      * @var RandomSymbolGenerator\n 8      */\n 9     private $randomGenerator;\n10 \n11     public function __construct(RandomSymbolGenerator $randomGenerator)\n12     {\n13         $this->randomGenerator = $randomGenerator;\n14     }\n15 \n16     public function generate(): string\n17     {\n18         $password = '';\n19         while (strlen($password) < self::MINIMUM_LENGTH) {\n20             $password .= $this->randomGenerator->generate();\n21         }\n22 \n23         return $password;\n24     }\n25 }\n

\n\n\n\n

¿Es esto un refactor o implementación distinta? Es un tema interesante para discutir, pero desde el punto de vista de la especificación es un refactor. Estos son los resultados que obtenemos al ejecutar nuestro playground:

\n\n

 1 tieprois\n 2 noulxius\n 3 suonpruol\n 4 veudhos\n 5 zimuan\n 6 faufreus\n 7 kadtaud\n 8 toidblor\n 9 fruedñeur\n10 geiñiu\n11 xiehel\n

\n\n\n\n

En realidad estamos tan contentos con el resultado que no vamos a cambiar el tipo de sílabas, aunque estamos pensando que la especificación de seis caracteres como mínimo es demasiado corta.

\n\n

Queremos contraseñas más difíciles

\n\n

Todavía nos quedan más requisitos que cumplir. Tenemos que hacer que algunos caracteres estén en mayúsculas y otros sean números o símbolos para lograr que la contraseña sea más difícil de adivinar.

\n\n

Cambiar algunas letras por sus mayúsculas no afecta en exceso a la legibilidad, si acaso un poco a la facilidad para recordarlas.

\n\n

Por otra parte, el tema de los números y los símbolos lo complica. Por supuesto, estamos pensando en hacer un poco de escritura H4cK3r, introduciendo símbolos o números que tengan semejanza gráfica con las letras.

\n\n

Es hora de aplicar el principio Abierto/Cerrado.

\n\n

Hackerizando la contraseña

\n\n

El principio Abierto/Cerrado dice que para modificar el comportamiento de un módulo de software existente no deberíamos modificarlo (cerrado a modificación), sino extenderlo (abierto a extensión).

\n\n

En un desarrollo agile, PasswordGenerator en su estado actual sería un buen primer entregable, de modo que es posible que lo pudiésemos tener en producción incluso usándose en varias partes de nuestra aplicación.

\n\n

Puede incluso que, para algunos de esos usos, la funcionalidad actual sea más que suficiente y cambiarla podría ocasionar problemas.

\n\n

Así que, ¿cómo cambiar la funcionalidad de PasswordGenerator sin romper el código que la utiliza en su estado actual?

\n\n

Decorándola.

\n\n

Decorar es extender por composición

\n\n

El patrón decorador es una gran solución para estos casos. La idea es tener un objeto con la misma interfaz que el decorado, al cual utiliza mientras modifica su comportamiento en ciertos aspectos.

\n\n

Los decoradores extienden el comportamiento de otros objetos por composición, no por herencia. De hecho, eso nos permite combinar varios decoradores para obtener comportamientos complejos montados a base de comportamientos más simples.

\n\n

Como veremos, además, los decoradores un gran ejemplo de aplicación de principios SOLID:

\n\n

SRP: un decorador para cada variedad específica de comportamiento
OCP: no hay que tocar el objeto original
LSP: el objeto base y el decorado son intercambiables
ISP: cuanto más específica la interfaz, más fácil crear decoradores
DIP: los decoradores y el objeto decorado dependen de interfaces

\n\n

Por ejemplo, nosotros queremos decorar nuestras contraseñas para que tengan dos características:

\n\n

Símbolos y números
Alguna mayúscula

\n\n

Eso son dos responsabilidades, así que necesitaremos dos decoradores.

\n\n

Decorador hacker

\n\n

Este decorador simplemente tomará la contraseña generada por un PasswordGenerator con el que se compone y convertirá algunos de sus caracteres en símbolos y números.

\n\n

Para ello nos interesa que cumpla una interfaz que aún no hemos definido pero que es la misma de PasswordGenerator: disponer de un método generate que devuelve un string. ¿Es el decorador un PasswordGenerator? En cierto modo sí, aunque es más bien un modificador.

\n\n

¿Por qué estas disquisiciones? Porque queremos que se cumpla el principio de Liskov y para eso necesitamos una misma interfaz y queremos declararla de forma explícita para poder usar Type Hinting en los casos necesarios. Ahora mismo PasswordGenerator es una implementación concreta y eso complica un poco el naming.

\n\n

Una solución sería crear una interfaz Generator, que tenga un método generate, lo que nos permite no tocar la clase PasswordGenerator salvo para hacer que la implemente, lo que es trivial y no rompe ningún test.

\n\n

1 namespace TalkingBit\\Readable;\n2 \n3 interface Generator\n4 {\n5     public function generate(): string;\n6 }\n

\n\n\n\n

Ahora ya podemos empezar con nuestro Hackerize. Pero primero, un test:

\n\n

 1 namespace Tests\\TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Decorator\\Hackerize;\n 4 use PHPUnit\\Framework\\TestCase;\n 5 use TalkingBit\\Readable\\Generator;\n 6 \n 7 class HackerizeTest extends TestCase\n 8 {\n 9 \n10     public function testConvertsAto4()\n11     {\n12         $generatorProphecy = $this->prophesize(Generator::class);\n13         $generatorProphecy->generate()->willReturn('a');\n14         $hackerize = new Hackerize($generatorProphecy->reveal());\n15         $this->assertEquals('4', $hackerize->generate());\n16     }\n17 }\n

\n\n\n\n

Empezamos con este test bastante sencillo, y creamos una implementación mínima:

\n\n

 1 namespace TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Generator;\n 4 \n 5 class Hackerize implements Generator\n 6 {\n 7 \n 8     public function generate(): string\n 9     {\n10         return '4';\n11     }\n12 }\n

\n\n\n\n

Fíjate que no necesitamos para nada el generador real, ni ninguna de sus dependencias, tan sólo estamos usando un stub que nos devuelve los valores de contraseña que nos interesan.

\n\n

Dado que vamos a tener contraseñas de varios caracteres, vamos a forzar una nueva implementación con este test:

\n\n

1     public function testConvertsSeveralChars()\n2     {\n3         $generatorProphecy = $this->prophesize(Generator::class);\n4         $generatorProphecy->generate()->willReturn('ae');\n5         $hackerize = new Hackerize($generatorProphecy->reveal());\n6         $this->assertEquals('43', $hackerize->generate());\n7     }\n

\n\n\n\n

Este test falla, como toca. Lo cierto es que podríamos seguir haciendo implementaciones inflexibles ad infinitum, así que vamos a pasar ya a una implementación razonablemente funcional:

\n\n

 1 namespace TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Generator;\n 4 \n 5 class Hackerize implements Generator\n 6 {\n 7     private const CHARS = ['a', 'e'];\n 8     private const SUBSTITUTIONS = ['4', '3'];\n 9     /**\n10      * @var Generator\n11      */\n12     private $generator;\n13 \n14     public function __construct(Generator $generator)\n15     {\n16         $this->generator = $generator;\n17     }\n18 \n19     public function generate(): string\n20     {\n21         $password = $this->generator->generate();\n22 \n23         return str_replace(self::CHARS, self::SUBSTITUTIONS, $password);\n24     }\n25 }\n

\n\n\n\n

Una cosa que debemos tener en cuenta es tener en cuenta las mayúsculas, de modo que nos de igual el caso. Hagamos un test para eso:

\n\n

1     public function testConvertsAto4CaseInsensitive()\n2     {\n3         $generatorProphecy = $this->prophesize(Generator::class);\n4         $generatorProphecy->generate()->willReturn('A');\n5         $hackerize = new Hackerize($generatorProphecy->reveal());\n6         $this->assertEquals('4', $hackerize->generate());\n7     }\n

\n\n\n\n

Y, oye, que basta un cambio mínimo para lograrlo str_ireplace en lugar de str_replace:

\n\n

 1 namespace TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Generator;\n 4 \n 5 class Hackerize implements Generator\n 6 {\n 7     private const CHARS = ['a', 'e'];\n 8     private const SUBSTITUTIONS = ['4', '3'];\n 9     /**\n10      * @var Generator\n11      */\n12     private $generator;\n13 \n14     public function __construct(Generator $generator)\n15     {\n16         $this->generator = $generator;\n17     }\n18 \n19     public function generate(): string\n20     {\n21         $password = $this->generator->generate();\n22 \n23         return str_ireplace(self::CHARS, self::SUBSTITUTIONS, $password);\n24     }\n25 }\n

\n\n\n\n

Realmente, sólo nos queda añadir más sustituciones de símbolos. Podemos refactorizar los tests con un data provider y dejarlo todo más limpio:

\n\n

 1 namespace Tests\\TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Decorator\\Hackerize;\n 4 use PHPUnit\\Framework\\TestCase;\n 5 use TalkingBit\\Readable\\Generator;\n 6 \n 7 class HackerizeTest extends TestCase\n 8 {\n 9     /** @dataProvider examplesProvider */\n10     public function testHackerizeAPassword($password, $hackerized)\n11     {\n12         $generatorProphecy = $this->prophesize(Generator::class);\n13         $generatorProphecy->generate()->willReturn($password);\n14         $hackerize = new Hackerize($generatorProphecy->reveal());\n15         $this->assertEquals($hackerized, $hackerize->generate());\n16     }\n17 \n18     public function examplesProvider()\n19     {\n20         return [\n21             'Single A' => ['aA', '44'],\n22             'Single E' => ['eE', '33'],\n23             'Single S' => ['sS', '$$'],\n24             'Single I' => ['iI', '!!'],\n25             'Single O' => ['oO', '00'],\n26             'Password' => ['Hackerized', 'H4ck3r!z3d']\n27         ];\n28     }\n29 }\n

\n\n\n\n

La implementación final será:

\n\n

 1 namespace TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Generator;\n 4 \n 5 class Hackerize implements Generator\n 6 {\n 7     private const CHARS = ['a', 'e', 'i', 'o', 's'];\n 8     private const SUBSTITUTIONS = ['4', '3', '!', '0', '$'];\n 9     /**\n10      * @var Generator\n11      */\n12     private $generator;\n13 \n14     public function __construct(Generator $generator)\n15     {\n16         $this->generator = $generator;\n17     }\n18 \n19     public function generate(): string\n20     {\n21         $password = $this->generator->generate();\n22 \n23         return str_ireplace(self::CHARS, self::SUBSTITUTIONS, $password);\n24     }\n25 }\n

\n\n\n\n

Decorador con mayúsculas

\n\n

Como PasswordGenerator sólo usa minúsculas para construir contraseñas, nos piden aumentar la dificultad añadiendo alguna letra mayúscula. Nosotros vamos a incluir una al azar.

\n\n

Lo suyo es comenzar con un test muy sencillo, que fallará:

\n\n

 1 namespace Tests\\TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Decorator\\RandomUpperize;\n 4 use PHPUnit\\Framework\\TestCase;\n 5 use TalkingBit\\Readable\\Generator;\n 6 \n 7 class RandomUpperizeTest extends TestCase\n 8 {\n 9     public function testUpperizeAPassword()\n10     {\n11         $generatorProphecy = $this->prophesize(Generator::class);\n12         $generatorProphecy->generate()->willReturn('m');\n13         $upperize = new RandomUpperize($generatorProphecy->reveal());\n14         $this->assertEquals('M', $upperize->generate());\n15     }\n16 }\n

\n\n\n\n

Momento de empezar a implementar:

\n\n

 1 namespace TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Generator;\n 4 \n 5 class RandomUpperize implements Generator\n 6 {\n 7 \n 8     /** @var Generator */\n 9     private $generator;\n10 \n11     public function __construct(Generator $generator)\n12     {\n13         $this->generator = $generator;\n14     }\n15 \n16     public function generate(): string\n17     {\n18         return 'M';\n19     }\n20 }\n

\n\n\n\n

Para forzar un cambio de implementación, podemos intentar convertir otra contraseña:

\n\n

1     public function testUpperizeTPassword()\n2     {\n3         $generatorProphecy = $this->prophesize(Generator::class);\n4         $generatorProphecy->generate()->willReturn('t');\n5         $upperize = new RandomUpperize($generatorProphecy->reveal());\n6         $this->assertEquals('T', $upperize->generate());\n7     }\n

\n\n\n\n

Y podríamos seguir hasta cansarnos, así que una implementación general sencilla podría ser la siguiente, de momento:

\n\n

 1 namespace TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Generator;\n 4 \n 5 class RandomUpperize implements Generator\n 6 {\n 7 \n 8     /** @var Generator */\n 9     private $generator;\n10 \n11     public function __construct(Generator $generator)\n12     {\n13         $this->generator = $generator;\n14     }\n15 \n16     public function generate(): string\n17     {\n18         return mb_strtoupper($this->generator->generate());\n19     }\n20 }\n

\n\n\n\n

El caso es que hemos dicho que queremos poner en mayúscula una letra al azar y para probar eso necesitamos dos cosas: contraseñas con varias letras para probar y algo que nos genere aleatoridad.

\n\n

Este último problema ya lo conocemos ¿Recuerdas que tenemos un generador de números aleatorios en este paquete que estamos creando?

\n\n

Por otro lado, queremos comprobar que las contraseñas decoradas sólo tienen una letra mayúscula, cosa que podemos hacer eliminado las minúsculas en el resultado y contando lo que quede.

\n\n

 1     public function testRandomlyUpperizeOnePassword()\n 2     {\n 3         $generatorProphecy = $this->prophesize(Generator::class);\n 4         $generatorProphecy->generate()->willReturn('password');\n 5         $randomnessProphecy = $this->prophesize(RandomnessEngine::class);\n 6         $randomnessProphecy->pickIntegerBetween(Argument::cetera())->willReturn(0);\n 7         $upperize = new RandomUpperize($generatorProphecy->reveal(), $randomnessProp\\\n 8 hecy->reveal());\n 9         $this->assertEquals(1, strlen(preg_replace('/[a-z]/', '', $upperize->generat\\\n10 e())));\n11     }\n

\n\n\n\n

Como test es un poco feo, pero hace lo que necesitamos.

\n\n

La implementación quedaría así:

\n\n

 1 namespace TalkingBit\\Readable\\Decorator;\n 2 \n 3 use TalkingBit\\Readable\\Generator;\n 4 use TalkingBit\\Readable\\RandomnessEngine;\n 5 \n 6 class RandomUpperize implements Generator\n 7 {\n 8 \n 9     /** @var Generator */\n10     private $generator;\n11     /**\n12      * @var RandomnessEngine\n13      */\n14     private $randomnessEngine;\n15 \n16     public function __construct(Generator $generator, RandomnessEngine $randomnessEn\\\n17 gine)\n18     {\n19         $this->generator = $generator;\n20         $this->randomnessEngine = $randomnessEngine;\n21     }\n22 \n23     public function generate(): string\n24     {\n25         $password = $this->generator->generate();\n26         $thisChar = $this->randomnessEngine->pickIntegerBetween(0, strlen($password)\\\n27 -1);\n28         $password[$thisChar] = mb_strtoupper($password[$thisChar]);\n29         return $password;\n30     }\n31 }\n

\n\n\n\n

Veamos cómo usarlo

\n\n

Vamos a ver ahora cómo montar nuestro generador de contraseñas con todas estas piezas:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 use TalkingBit\\Readable\\Decorator\\Hackerize;\n 4 \n 5 require_once '../vendor/autoload.php';\n 6 \n 7 $passwordGenerator = new PasswordGenerator(\n 8     new RandomSyllableSymbolGenerator(\n 9         new SystemRandomnessEngine()\n10     )\n11 );\n12 \n13 $passwordGenerator = new Hackerize($passwordGenerator);\n14 \n15 for ($count = 0; $count <= 10; $count++) {\n16     print $passwordGenerator->generate() . PHP_EOL;\n17 }\n

\n\n\n\n

Que da como resultado:

\n\n

 1 c4ntr!0n\n 2 ch3!ng!0n\n 3 br4!z3u\n 4 blu0dpl4!d\n 5 u3nq0!l\n 6 cr0udg4un\n 7 h!3dyu4\n 8 c3ul4d\n 9 z!4dcr!u$\n10 ru3$cl0d\n11 mu!dyu3$\n

\n\n\n\n

¿Y si le añadimos mayúsculas?

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 use TalkingBit\\Readable\\Decorator\\RandomUpperize;\n 4 \n 5 require_once '../vendor/autoload.php';\n 6 \n 7 $passwordGenerator = new PasswordGenerator(\n 8     new RandomSyllableSymbolGenerator(\n 9         new SystemRandomnessEngine()\n10     )\n11 );\n12 \n13 $passwordGenerator = new RandomUpperize($passwordGenerator, new SystemRandomnessEngi\\\n14 ne());\n15 \n16 for ($count = 0; $count <= 10; $count++) {\n17     print $passwordGenerator->generate() . PHP_EOL;\n18 }\n

\n\n\n\n

Pues sale esto:

\n\n

 1 kaDfrais\n 2 siadMuin\n 3 blIossun\n 4 Chaunmier\n 5 prierpuAr\n 6 flouquoS\n 7 plaurloiL\n 8 crausqAur\n 9 ñaunfrIod\n10 gausTriar\n11 zuanBlues\n

\n\n\n\n

Y, finalmente, combinando ambos decoradores:

\n\n

 1 namespace TalkingBit\\Readable;\n 2 \n 3 use TalkingBit\\Readable\\Decorator\\Hackerize;\n 4 use TalkingBit\\Readable\\Decorator\\RandomUpperize;\n 5 \n 6 require_once '../vendor/autoload.php';\n 7 \n 8 $passwordGenerator = new PasswordGenerator(\n 9     new RandomSyllableSymbolGenerator(\n10         new SystemRandomnessEngine()\n11     )\n12 );\n13 \n14 $passwordGenerator = new RandomUpperize($passwordGenerator, new SystemRandomnessEngi\\\n15 ne());\n16 $passwordGenerator = new Hackerize($passwordGenerator);\n17 \n18 for ($count = 0; $count <= 10; $count++) {\n19     print $passwordGenerator->generate() . PHP_EOL;\n20 }\n

\n\n\n\n

Con este resultado, que legible, lo que se dice legible, tampoco lo es mucho:

\n\n

 1 chu0$q4!d\n 2 H!4$fl3l\n 3 v0Dwu0\n 4 fl!Urqu0d\n 5 ll0u$fr3!$\n 6 p3!nfr3!N\n 7 x3rll3r\n 8 du!lbl4!n\n 9 ku3lu3d\n10 br3lH4!\n11 $4dLlu0l\n

\n\n\n\n

Cosas por hacer

\n\n

Espero que el artículo haya servido para ilustrar un caso realista de testeo no determinista, aunque quizá se me ha ido un poco de las manos.

\n\n

En cualquier caso, este proyecto está abierto a varias mejoras que se podrían tratar en artículos posteriores:

\n\n

Dada la complejidad de montar un generador de contraseñas con todas las piezas que hemos creado, podría estar bien introducir el patrón factoría a fin de simplificarlo.
Otro tema sería poder modular un poco la complejidad de las contraseñas generadas para que aún transformadas no sean tan ilegibles.
Por último, la posibilidad de montar un paquete para poder instalar el generador como dependencia mediante composer en otros proyectos en los que queramos utilzarlo.

\n\n

Algunas referencias

\n\n

Finalmente, algunas referencias sobre el tema que he seguido para fundamentar el artículo:

\n\n

Eradicating Non-Determinism in Tests
\nEste hilo de Stack Exchange

\n\n\n

TDD en PHP. Un ejemplo con colecciones (1)

\n\n

Arrays…

\n\n

En PHP hemos utilizado arrays para todo tipo de cosas: listas, diccionarios, persistencia en memoria, registros y un largo etcétera.

\n\n

Lo malo de los arrays es que necesitan mucha supervisión adulta. Al fin y al cabo, nada nos impide hacer cosas como estas:

\n\n

1 $store = [];\n2 $store[] = new MyClass();\n3 $store[] = new AnotherClass();\n4 $store[] = 'random string';\n

\n\n\n\n

Es decir, la única forma de garantizar que almacenamos en un array objetos de un tipo determinado, y siempre del mismo, es controlarlo en el momento de añadirlo, pero también en el de usarlo ya que entre un punto y otro del flujo puede haber pasado cualquier cosa con nuestro array.

\n\n

Una solución es encapsular el array en algún tipo de objeto Collection, que se encargue de asegurar que sólo incorporamos objetos válidos y que pueda realizar ciertas operaciones con ellos, garantizándonos la coherencia de los datos en todo momento.

\n\n

Existen diversas librerías que aportan colecciones en PHP, a Google pronto:

\n\n

https://github.com/morrisonlevi/Ardent
\nhttps://github.com/allebb/collection
\nhttps://github.com/emonkak/php-collection
\nhttps://dusankasan.github.io/Knapsack/
\nhttp://jmsyst.com/libs/php-collection

\n\n

Incluso parece que tendremos una implementación canónica en un futuro

\n\n

http://php.net/manual/en/class.ds-collection.php

\n\n

Sin embargo siempre es interesante reinventar la rueda para profundizar en un concepto, así que mi intención en este capítulo y los siguientes es desarrollar una clase Collection usando TDD e ilustrando el proceso de desarrollo. El proyecto original está en Github por si te interesa seguirlo más en detalle.

\n\n

El objetivo es mostrar un proyecto bastante desarrollado desde el inicio mediante TDD.

\n\n

¿Qué tendría que tener una clase Collection?

\n\n

Hagamos una lista de control. Fundamentalmente pienso que necesitamos:

\n\n

Poder añadir elementos a la colección
Que estos elementos sean objetos
Que pueda decirnos cuántos objetos está almacenando
Que sólo pueda añadir objetos de la misma clase o interfaz
Que pueda añadir objetos de subclases de la original
Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)

\n\n

Escribiendo el primer mínimo test que falle

\n\n

Decidir el primer test siempre tiene su dificultad. Después de un tiempo usando PHPSpec muchas veces comienzo con un test que chequee que puedo instanciar la clase, incluso en PHPUnit, que es el entorno de test que voy a utilizar. Quedaría algo así:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9 \n10     public function testShouldInitialize()\n11     {\n12         $this->instanceOf(Collection::class, new Collection());\n13     }\n14 }\n

\n\n\n\n

Es posible este test acabe desapareciendo, una vez que hayamos hecho avanzar un poco el código. La ventaja es que no hay que hacer mucho más que definir la clase para que el test pase, lo que viene siendo un código mínimo de producción.

\n\n

1 <?php\n2 namespace Fi\\Collections;\n3 \n4 class Collection\n5 {\n6 }\n

\n\n\n\n

Alternativamente, o a la vez, podemos escribir un test algo menos minimalista, por ejemplo, un test que verifique que al instanciar la clase tenemos una colección vacía. Eso ya implica crear un método count que nos proporcione esa información.

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9     public function testShouldInitialize()\n10     {\n11         $this->assertInstanceOf(Collection::class, new Collection());\n12     }\n13 \n14     public function testShouldBeConstructedEmpty()\n15     {\n16         $sut = new Collection();\n17         $this->assertEquals(0, $sut->count());\n18     }\n19 }\n

\n\n\n\n

Este test nos obliga a crear un primer método count, que devolverá 0. Para ello, escribimos el mínimo código de producción que haga que el test pase:

\n\n

 1 <?php\n 2 namespace Fi\\Collections;\n 3 \n 4 class Collection\n 5 {\n 6     public function count()\n 7     {\n 8         return 0;\n 9     }\n10 }\n

\n\n\n\n

En fin, puede que te parezca que de momento vamos muy lentos. Esto es lo que Kent Beck llama baby steps. También dice que cada quien tiene que encontrar el tamaño ideal de sus baby steps incluso dependiendo de cómo nos estemos encontrando en cada fase de desarrollo. Es decir, no hay una medida fija de cuál es el mínimo test o el mínimo código de producción, sino que es algo que podemos modular en función de las necesidades que percibimos al trabajar.

\n\n

Pongamos un poco de comportamiento aquí

\n\n

Nuestra lista de tareas empieza a tener algunos elementos menos:

\n\n

Poder añadir elementos a la colección
Que estos elementos sean objetos
Que pueda decirnos cuántos objetos está almacenando
Que sólo pueda añadir objetos de la misma clase o interfaz
Que pueda añadir objetos de subclases de la original
Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)

\n\n

Bien. Una colección no es nada si no puede coleccionar cosas, así que queremos poder añadirle elementos. Hagamos un test que lo pruebe:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9     public function testShouldInitialize()\n10     {\n11         $this->assertInstanceOf(Collection::class, new Collection());\n12     }\n13 \n14     public function testShouldBeConstructedEmpty()\n15     {\n16         $sut = new Collection();\n17         $this->assertEquals(0, $sut->count());\n18     }\n19 \n20     public function testShouldBeAbleToAppendOneElement()\n21     {\n22         $sut = new Collection();\n23         $sut->append(new class{});\n24         $this->assertEquals(1, $sut->count());\n25     }\n26 }\n

\n\n\n\n

Dos cosas interesantes aquí:

\n\n

La primera es: ¿por qué testeamos ahora y no antes la capacidad de añadir elementos a la lista? Este es un pequeño debate que mantuve conmigo mismo mientras iba escribiendo. Lo cierto es que el test de la colección vacía es más pequeño y el código que me pide añadir es también menor. Una colección vacía no deja de ser una colección. La siguiente cosa más complicada es tener una colección con al menos un elemento.

\n\n

La segunda está en la línea $this->append(new class{});. Se trata de una clase anónima. Es un constructo del lenguaje bastante interesante, con ciertas similitudes con las funciones anónimas, para definir clases sobre la marcha. En este caso nos sirve para obtener un objeto sin tener que definir una clase particular.

\n\n

Y esta es mi propuesta para pasar el test:

\n\n

 1 <?php\n 2 namespace Fi\\Collections;\n 3 \n 4 class Collection\n 5 {\n 6     private $elements;\n 7 \n 8     public function count()\n 9     {\n10         return count($this->elements);\n11     }\n12 \n13     public function append($element)\n14     {\n15         $this->elements[] = $element;\n16     }\n17 }\n

\n\n\n\n

Hemos tenido que añadir un poquito de código para lograr pasar el nuevo test y no romper el anterior. Aquí se puede apreciar que nuestro test de Collection vacía es útil: para no romperlo tenemos que asegurar que el método count devuelve 0 si no hemos añadido ningún elemento a la colección.

\n\n

Para triangular este test, podríamos controlar que podemos añadir algún elemento más:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9     public function testShouldInitialize()\n10     {\n11         $this->assertInstanceOf(Collection::class, new Collection());\n12     }\n13 \n14     public function testShouldBeConstructedEmpty()\n15     {\n16         $sut = new Collection();\n17         $this->assertEquals(0, $sut->count());\n18     }\n19 \n20     public function testShouldBeAbleToAppendOneElement()\n21     {\n22         $sut = new Collection();\n23         $sut->append(new class{});\n24         $this->assertEquals(1, $sut->count());\n25     }\n26 \n27     public function testShouldBeAbleToAppendTwoElements()\n28     {\n29         $sut = new Collection();\n30         $sut->append(new class{});\n31         $sut->append(new class{});\n32         $this->assertEquals(2, $sut->count());\n33     }\n34 }\n

\n\n\n\n

Y este test nos sale directamente en verde.

\n\n

Siempre que un nuevo test nos sale en verde nos plantea una disyuntiva: o bien el test pasa porque ya hemos hecho la implementación obvia general o bien el test pasa porque no estamos testeando lo que debemos.

\n\n

El caso es que nuestra implementación era bastante obvia y resulta que es la implementación general, así que, podríamos decir que este último test incluso sobra.

\n\n

Controlando qué ponemos en la colección

\n\n

Repasemos lo conseguido hasta ahora:

\n\n

Poder añadir elementos a la colección
Que estos elementos sean objetos
Que pueda decirnos cuántos objetos está almacenando
Que sólo pueda añadir objetos de la misma clase o interfaz
Que pueda añadir objetos de subclases de la original
Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)

\n\n

Para asegurar que los elementos que añadimos a la colección sean objetos y que sean de un tipo lo primero que tenemos que hacer es un test que lo pruebe. Lo cierto es que si podemos asegurar que son objetos de una clase, automáticamente estamos validando la condición de que sean objetos.

\n\n

Si pasamos un objeto de la clase incorrecta deberíamos tener una excepción. En este caso he optado por OutOfBoundsException. Podríamos cambiarla más adelante por otra más explícita ya que no es lo más importante de nuestro proyecto.

\n\n

Y es ahora cuando empiezan los problemas: ¿Cómo testeamos esto? ¿Cómo sabe Collection qué tipos son válidos y cuáles no? Empecemos por el test más básico:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9 \t/* The other tests ... */\n10 \t\n11     public function testShouldNotStoreObjectOfIncorrectType()\n12     {\n13         $sut = new Collection();\n14         $this->expectException(\\OutOfBoundsException::class);\n15         $sut->append(new class{});\n16     }\n17 }\n

\n\n\n\n

Este test fallará, lo que está bien.

\n\n

Pero para pasar a verde vamos a tener pensar varias cosas. Una forma podría ser simplemente hacer un Type Hinting en el método append, pero ¿contra qué tipo? Si fijamos un type hinting en append no vamos a poder extender la clase Collection para poder usar otros tipos, así que tenemos que buscar otra forma de controlarlo.

\n\n

Por otra parte, la clase Collection necesitará saber contra qué tipo validar los objetos que le añadamos y ese conocimiento debería ser obligatorio. Por tanto, nos hace falta un test previo para controlar que puedo definir el tipo de la colección:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9 \t/* The other tests ... */\n10 \t\n11     public function testShouldInitializeWithAType()\n12     {\n13         $sut = new Collection(get_class($this));\n14         $this->assertInstanceOf(Collection::class, $sut);\n15     }\n16 \n17     public function testShouldNotStoreObjectOfIncorrectType()\n18     {\n19         $sut = new Collection();\n20         $this->expectException(\\OutOfBoundsException::class);\n21         $sut->append(new class{});\n22     }\n23 }\n

\n\n\n\n

La nota interesante en este caso es esa especie de self-shunt que nos hemos marcado. En lugar de inventarnos un tipo, usamos el propio tipo de nuestro TestCase. De paso, modificamos el test anterior.

\n\n

La técnica de Self-shunt consiste en utilizar el propio TestCase como Doble para los tests, así no tienes que crear nuevas clases para tener un objeto que pasar. Aprendí esta técnica en las Rigor Talks de Carlos Buenosvinos.

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9 \t/* The other tests ... */\n10 \t\n11     public function testShouldInitializeWithAType()\n12     {\n13         $sut = new Collection(get_class($this));\n14         $this->assertInstanceOf(Collection::class, $sut);\n15     }\n16 \n17     public function testShouldNotStoreObjectOfIncorrectType()\n18     {\n19         $sut = new Collection(get_class($this));\n20         $this->expectException(\\OutOfBoundsException::class);\n21         $sut->append(new class{});\n22     }\n23 }\n

\n\n\n\n

Para pasar este test, necesitamos añadir un constructor a nuestra clase que admita un parámetro en forma de string que sea opcional, a fin de no romper los tests anteriores.

\n\n

 1 <?php\n 2 \n 3 namespace Fi\\Collections;\n 4 \n 5 class Collection\n 6 {\n 7     private $elements;\n 8     /**\n 9      * @var string\n10      */\n11     private $type;\n12 \n13     public function __construct(string $type = null)\n14     {\n15         $this->type = $type;\n16     }\n17 \n18     public function count()\n19     {\n20         return count($this->elements);\n21     }\n22 \n23     public function append($element)\n24     {\n25         $this->elements[] = $element;\n26     }\n27 }\n

\n\n\n\n

Ahora podemos crear Collections con tipo, pero quizá deberíamos parar un momento y refactorizar nuestros tests, la duplicación que tenemos puede ponerse problemática.

\n\n

Refactorizar el test

\n\n

Refactorizamos los tests porque son parte integral de nuestro desarrollo. Y como también son código deberíamos aplicar las mismas buenas prácticas que a nuestro código de producción.

\n\n

En este caso debería ser evidente que hay una duplicación importante: cada vez que instanciamos nuestro Subject Under Test repetimos el mismo código y, aunque puede parecer trivial, nos conviene reducirla extrayendo el código común a un método.

\n\n

También hay una repetición en los dos test que inicializan Collection especificando un tipo, así que también lo extraemos:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9     public function testShouldInitialize()\n10     {\n11         $this->assertInstanceOf(Collection::class, $this->getCollection());\n12     }\n13 \n14     public function testShouldBeConstructedEmpty()\n15     {\n16         $sut = $this->getCollection();\n17         $this->assertEquals(0, $sut->count());\n18     }\n19 \n20     public function testShouldBeAbleToAppendOneElement()\n21     {\n22         $sut = $this->getCollection();\n23         $sut->append(new class{});\n24         $this->assertEquals(1, $sut->count());\n25     }\n26 \n27     public function testShouldBeAbleToAppendTwoElements()\n28     {\n29         $sut = $this->getCollection();\n30         $sut->append(new class{});\n31         $sut->append(new class{});\n32         $this->assertEquals(2, $sut->count());\n33     }\n34 \t\n35     public function testShouldInitializeWithAType()\n36     {\n37         $sut = $this->getTypedCollection();\n38         $this->assertInstanceOf(Collection::class, $sut);\n39     }\n40 \n41     public function testShouldNotStoreObjectOfIncorrectType()\n42     {\n43         $sut = $this->getTypedCollection();\n44         $this->expectException(\\OutOfBoundsException::class);\n45         $sut->append(new class{});\n46     }\n47 \n48     protected function getCollection(): Collection\n49     {\n50         $sut = new Collection();\n51         return $sut;\n52     }\n53 \t\n54     protected function getTypedCollection(): Collection\n55     {\n56         $sut = new Collection(get_class($this));\n57         return $sut;\n58     }\n59 }\n

\n\n\n\n

De momento, se queda así.

\n\n

Ahora bien, nuestro test para controlar que Collection sólo admite objetos de un tipo sigue fallando y tendremos que hacer algo al respecto para ponernos en verde.

\n\n

Parece que es obvio que hay que añadir un control que compare el tipo del objeto que se pasa en append con el que hemos registrado en Collection.

\n\n

 1 <?php\n 2 \n 3 namespace Fi\\Collections;\n 4 \n 5 class Collection\n 6 {\n 7     private $elements;\n 8     /**\n 9      * @var string\n10      */\n11     private $type;\n12 \n13     public function __construct(string $type = null)\n14     {\n15         $this->type = $type;\n16     }\n17 \n18     public function count()\n19     {\n20         return count($this->elements);\n21     }\n22 \n23     public function append($element)\n24     {\n25         if (get_class($element) !== $this->type) {\n26             throw new \\UnexpectedValueException('Invalid Type');\n27         }\n28         $this->elements[] = $element;\n29     }\n30 }\n

\n\n\n\n

Esto va a hacer que fallen nuestros tests anteriores porque al hacer que type sea opcional, también tenemos que asegurarnos de que controlamos el tipo sólo si tenemos alguno definido. Esto va a suponer un problema conceptual que tendremos que tratar, pero de momento vamos a aparcarlo.

\n\n

El código de producción tendría que quedar así:

\n\n

 1 <?php\n 2 \n 3 namespace Fi\\Collections;\n 4 \n 5 class Collection\n 6 {\n 7     private $elements;\n 8     /**\n 9      * @var string\n10      */\n11     private $type;\n12 \n13     public function __construct(string $type = null)\n14     {\n15         $this->type = $type;\n16     }\n17 \n18     public function count()\n19     {\n20         return count($this->elements);\n21     }\n22 \n23     public function append($element)\n24     {\n25         if (!is_null($this->type) && get_class($element) !== $this->type) {\n26             throw new \\OutOfBoundsException('Invalid Type');\n27         }\n28         $this->elements[] = $element;\n29     }\n30 }\n

\n\n\n\n

Ya que estamos, vamos a testear e implementar que podemos añadir objetos que sean subclase del tipo aceptado por la lista. Test que falle al canto:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9 \t/* The other tests */\n10 \n11     public function testShouldNotStoreObjectOfIncorrectType()\n12     {\n13         $sut = $this->getTypedCollection();\n14         $this->expectException(\\OutOfBoundsException::class);\n15         $sut->append(new class{});\n16     }\n17 \t\n18     public function testShouldBeAbleToStoreSubClasses()\n19     {\n20         $sut = $this->getTypedCollection();\n21         $sut->append(new class extends CollectionTest {});\n22         $this->assertEquals(1, $sut->count());\n23     }\n24 \n25     protected function getCollection(): Collection\n26     {\n27         $sut = new Collection();\n28         return $sut;\n29     }\n30 \t\n31     protected function getTypedCollection(): Collection\n32     {\n33         $sut = new Collection(get_class($this));\n34         return $sut;\n35     }\n36 }\n

\n\n\n\n

Nuestro test fallará. Esto es por que nuestro control del tipo es demasiado estricto, podemos relajarlo con is_a, una función que nos dice si un objeto es, o hereda, de la clase indicada:

\n\n

 1 <?php\n 2 \n 3 namespace Fi\\Collections;\n 4 \n 5 class Collection\n 6 {\n 7     private $elements;\n 8     /**\n 9      * @var string\n10      */\n11     private $type;\n12 \n13     public function __construct(string $type = null)\n14     {\n15         $this->type = $type;\n16     }\n17 \n18     public function count()\n19     {\n20         return count($this->elements);\n21     }\n22 \n23     public function append($element)\n24     {\n25         if (!is_null($this->type) && !is_a($element, $this->type)) {\n26             throw new \\UnexpectedValueException('Invalid Type');\n27         }\n28         $this->elements[] = $element;\n29     }\n30 }\n

\n\n\n\n

Ahora nuestro test pasa y es momento de refactorizar. Como se puede ver, la cláusula de guarda que hemos puesto para controlar el tipo hace rato que ha dejado de ser fácil de leer, por lo que sería buena idea extraerla y ocultar su complejidad en un método con un nombre más explícito.

\n\n

 1 <?php\n 2 \n 3 namespace Fi\\Collections;\n 4 \n 5 class Collection\n 6 {\n 7     /**\n 8      * @var array\n 9      */\n10     private $elements;\n11     /**\n12      * @var string\n13      */\n14     private $type;\n15 \n16     public function __construct(string $type = null)\n17     {\n18         $this->type = $type;\n19     }\n20 \n21     public function count()\n22     {\n23         return count($this->elements);\n24     }\n25 \n26     public function append($element)\n27     {\n28         $this->guardAgainstInvalidType($element);\n29         $this->elements[] = $element;\n30     }\n31 \n32     protected function guardAgainstInvalidType($element): void\n33     {\n34         if (!is_null($this->type) && !is_a($element, $this->type)) {\n35             throw new \\UnexpectedValueException('Invalid Type');\n36         }\n37     }\n38 }\n

\n\n\n\n

Por fin, podemos tachar algunos elementos de nuestra lista:

\n\n

Poder añadir elementos a la colección
Que estos elementos sean objetos
Que pueda decirnos cuántos objetos está almacenando
Que sólo pueda añadir objetos de la misma clase o interfaz
Que pueda añadir objetos de subclases de la original
Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)

\n\n

Antes de terminar, hagamos unos arreglos

\n\n

Ahora mismo hemos cubierto la mitad de nuestra lista pero, como mencioné antes, tenemos un problema conceptual importante que no hemos afrontado.

\n\n

Nuestra Collection maneja un tipo específico de datos, pero actualmente permitimos que se puedan crear instancias de Collection sin especificar tipo. Si hacemos que el tipo sea obligatorio en la construcción romperemos buena parte de los tests, por lo cual deberíamos refactorizarlos de nuevo. Y el caso es que nuestra anterior refactorización nos ayuda al centralizar la creación de Collections para tests.

\n\n

Lo haré en varios pasos.

\n\n

Primero, modificamos getCollection para que instancie la colección dándole un tipo (haciendo esta especie de self-shunt para no tener que añadir nada innecesario). Para eso nos basta con llamar internamente a getTypedCollection.

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9     public function testShouldInitialize()\n10     {\n11         $this->assertInstanceOf(Collection::class, $this->getCollection());\n12     }\n13 \n14     public function testShouldBeConstructedEmpty()\n15     {\n16         $sut = $this->getCollection();\n17         $this->assertEquals(0, $sut->count());\n18     }\n19 \n20     public function testShouldBeAbleToAppendOneElement()\n21     {\n22         $sut = $this->getCollection();\n23         $sut->append(new class {});\n24         $this->assertEquals(1, $sut->count());\n25     }\n26 \n27     public function testShouldBeAbleToAppendTwoElements()\n28     {\n29         $sut = $this->getCollection();\n30         $sut->append(new class {});\n31         $sut->append(new class {});\n32         $this->assertEquals(2, $sut->count());\n33     }\n34 \n35     public function testShouldInitializeWithAType()\n36     {\n37         $sut = $this->getTypedCollection();\n38         $this->assertInstanceOf(Collection::class, $sut);\n39     }\n40 \n41     public function testShouldNotStoreObjectOfIncorrectType()\n42     {\n43         $sut = $this->getTypedCollection();\n44         $this->expectException(\\UnexpectedValueException::class);\n45         $sut->append(new class {});\n46     }\n47 \n48     public function testShouldBeAbleToStoreSubClasses()\n49     {\n50         $sut = $this->getTypedCollection();\n51         $sut->append(new class extends CollectionTest {});\n52         $this->assertEquals(1, $sut->count());\n53     }\n54 \n55     private function getCollection(): Collection\n56     {\n57         return $this->getTypedCollection();\n58     }\n59 \n60     private function getTypedCollection(): Collection\n61     {\n62         return new Collection(get_class($this));\n63     }\n64 }\n

\n\n\n\n

Esto hace que fallen los tests que controlan que podemos añadir objetos a la colección. Era de esperar ya que estamos pasando clases anónimas, cambiemos eso haciendo un self-shunt.

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9     public function testShouldInitialize()\n10     {\n11         $this->assertInstanceOf(Collection::class, $this->getCollection());\n12     }\n13 \n14     public function testShouldBeConstructedEmpty()\n15     {\n16         $sut = $this->getCollection();\n17         $this->assertEquals(0, $sut->count());\n18     }\n19 \n20     public function testShouldBeAbleToAppendOneElement()\n21     {\n22         $sut = $this->getCollection();\n23         $sut->append($this);\n24         $this->assertEquals(1, $sut->count());\n25     }\n26 \n27     public function testShouldBeAbleToAppendTwoElements()\n28     {\n29         $sut = $this->getCollection();\n30         $sut->append($this);\n31         $sut->append($this);\n32         $this->assertEquals(2, $sut->count());\n33     }\n34 \n35     public function testShouldInitializeWithAType()\n36     {\n37         $sut = $this->getTypedCollection();\n38         $this->assertInstanceOf(Collection::class, $sut);\n39     }\n40 \n41     public function testShouldNotStoreObjectOfIncorrectType()\n42     {\n43         $sut = $this->getTypedCollection();\n44         $this->expectException(\\UnexpectedValueException::class);\n45         $sut->append(new class {});\n46     }\n47 \n48     public function testShouldBeAbleToStoreSubClasses()\n49     {\n50         $sut = $this->getTypedCollection();\n51         $sut->append(new class extends CollectionTest {});\n52         $this->assertEquals(1, $sut->count());\n53     }\n54 \n55     private function getCollection(): Collection\n56     {\n57         return $this->getTypedCollection();\n58     }\n59 \n60     private function getTypedCollection(): Collection\n61     {\n62         return new Collection(get_class($this));\n63     }\n64 }\n

\n\n\n\n

Ok. Ahora los tests pasan. Todavía podemos hacer un arreglillo: getCollection y getTypedCollection hacen exactamente lo mismo, así que podemos quitar uno de los dos. Creo que podemos dejar getCollection y que se quede con el código del otro método. Cambiamos las llamadas en los tests que hagan falta y el TestCase nos queda así.

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9     public function testShouldInitialize()\n10     {\n11         $this->assertInstanceOf(Collection::class, $this->getCollection());\n12     }\n13 \n14     public function testShouldBeConstructedEmpty()\n15     {\n16         $sut = $this->getCollection();\n17         $this->assertEquals(0, $sut->count());\n18     }\n19 \n20     public function testShouldBeAbleToAppendOneElement()\n21     {\n22         $sut = $this->getCollection();\n23         $sut->append($this);\n24         $this->assertEquals(1, $sut->count());\n25     }\n26 \n27     public function testShouldBeAbleToAppendTwoElements()\n28     {\n29         $sut = $this->getCollection();\n30         $sut->append($this);\n31         $sut->append($this);\n32         $this->assertEquals(2, $sut->count());\n33     }\n34 \n35     public function testShouldInitializeWithAType()\n36     {\n37         $sut = $this->getCollection();\n38         $this->assertInstanceOf(Collection::class, $sut);\n39     }\n40 \n41     public function testShouldNotStoreObjectOfIncorrectType()\n42     {\n43         $sut = $this->getCollection();\n44         $this->expectException(\\UnexpectedValueException::class);\n45         $sut->append(new class {});\n46     }\n47 \n48     public function testShouldBeAbleToStoreSubClasses()\n49     {\n50         $sut = $this->getCollection();\n51         $sut->append(new class extends CollectionTest {});\n52         $this->assertEquals(1, $sut->count());\n53     }\n54 \n55     private function getCollection(): Collection\n56     {\n57         return new Collection(get_class($this));\n58     }\n59 }\n

\n\n\n\n

Fíjate que siguen pasando los tests y que, en cierto modo, hemos usado el código de producción como “test del test” para hacer este refactoring.

\n\n

Ahora ya podemos tocar la clase Collection y ver si al hacer obligatoria la definición del tipo se rompe algo. La respuesta es que no. Además, podemos quitar el feo control de null, ya que ahora el parámetro siempre estará presente. Por cierto, que al ser privado y pasarse sólo en el constructor, resulta que es inmatuble desde fuera de Collection y eso es bueno.

\n\n

 1 <?php\n 2 \n 3 namespace Fi\\Collections;\n 4 \n 5 class Collection\n 6 {\n 7     /**\n 8      * @var array\n 9      */\n10     private $elements;\n11     /**\n12      * @var string\n13      */\n14     private $type;\n15 \n16     public function __construct(string $type)\n17     {\n18         $this->type = $type;\n19     }\n20 \n21     public function count()\n22     {\n23         return count($this->elements);\n24     }\n25 \n26     public function append($element)\n27     {\n28         $this->guardAgainstInvalidType($element);\n29         $this->elements[] = $element;\n30     }\n31 \n32     protected function guardAgainstInvalidType($element): void\n33     {\n34         if (!is_a($element, $this->type)) {\n35             throw new \\UnexpectedValueException('Invalid Type');\n36         }\n37     }\n38 }\n

\n\n\n\n

Y un extra

\n\n

Para ser más semánticos, podríamos añadir un named constructor de modo que la instanciación de nuevas colecciones se haga de una manera más expresiva. Algo así:

\n\n

1 $collection = Collection::of(Myclass::class);\n

\n\n\n\n

También haremos privado el constructor. Para eso podemos simplemente modificar el método factoría que tiene el test, automáticamente todos los tests fallarán, pero que no cunda el pánico:

\n\n

 1 <?php\n 2 namespace Test\\Collections;\n 3 \n 4 use Fi\\Collections\\Collection;\n 5 use PHPUnit\\Framework\\TestCase;\n 6 \n 7 class CollectionTest extends TestCase\n 8 {\n 9 \n10     public function testShouldInitialize()\n11     {\n12         $this->assertInstanceOf(Collection::class, $this->getCollection());\n13     }\n14 \n15     public function testShouldBeConstructedEmpty()\n16     {\n17         $sut = $this->getCollection();\n18         $this->assertEquals(0, $sut->count());\n19     }\n20 \n21     public function testShouldBeAbleToAppendOneElement()\n22     {\n23         $sut = $this->getCollection();\n24         $sut->append($this);\n25         $this->assertEquals(1, $sut->count());\n26     }\n27 \n28     public function testShouldBeAbleToAppendTwoElements()\n29     {\n30         $sut = $this->getCollection();\n31         $sut->append($this);\n32         $sut->append($this);\n33         $this->assertEquals(2, $sut->count());\n34     }\n35 \n36     public function testShouldInitializeWithAType()\n37     {\n38         $sut = $this->getCollection();\n39         $this->assertInstanceOf(Collection::class, $sut);\n40     }\n41 \n42     public function testShouldNotStoreObjectOfIncorrectType()\n43     {\n44         $sut = $this->getCollection();\n45         $this->expectException(\\UnexpectedValueException::class);\n46         $sut->append(new class {});\n47     }\n48 \n49     public function testShouldBeAbleToStoreSubClasses()\n50     {\n51         $sut = $this->getCollection();\n52         $sut->append(new class extends CollectionTest {});\n53         $this->assertEquals(1, $sut->count());\n54     }\n55 \n56     private function getCollection(): Collection\n57     {\n58         return Collection::of(get_class($this));\n59     }\n60 }\n

\n\n\n\n

Al fin y al cabo, sólo hay que hacer unas pequeñas modificaciones para volver a verde:

\n\n

 1 <?php\n 2 \n 3 namespace Fi\\Collections;\n 4 \n 5 class Collection\n 6 {\n 7     /**\n 8      * @var array\n 9      */\n10     private $elements;\n11     /**\n12      * @var string\n13      */\n14     private $type;\n15 \n16     private function __construct(string $type)\n17     {\n18         $this->type = $type;\n19     }\n20 \n21     public static function of(string $type)\n22     {\n23         return new self($type);\n24     }\n25 \n26     public function count()\n27     {\n28         return count($this->elements);\n29     }\n30 \n31     public function append($element)\n32     {\n33         $this->guardAgainstInvalidType($element);\n34         $this->elements[] = $element;\n35     }\n36 \n37     protected function guardAgainstInvalidType($element): void\n38     {\n39         if (!is_a($element, $this->type)) {\n40             throw new \\UnexpectedValueException('Invalid Type');\n41         }\n42     }\n43 }\n

\n\n\n\n

Fin del primer acto

\n\n

Con esto terminamos la primera parte, nuestra clase Collection admite objetos de una clase y sus subclases. También permite objetos que implementen la misma interfaz, algo que no hemos hecho explícito en los tests, pero que podría ser innecesario ya que el mecanismo de control de tipo funciona tanto para clases como para interfaces.

\n\n

Lo interesante creo que está en el proceso seguido y en algunas técnicas que hemos ido aplicando. Por ejemplo:

\n\n

El uso de TDD para modelar la clase Collection, usando el ciclo Rojo->Verde->Refactor.
El diálogo entre los tests y el código de producción, hasta el punto de que en algún momento el código de producción nos sirve como red de seguridad para refactorizar los tests.
La importancia de refactorizar tanto el código de producción como los tests.
El uso de clases anónimas para crear Dummies para tests.
El uso de técnicas self-shunt para evitar tener que crear clases o dobles para ciertos tests.
El uso de métodos factoría en los tests para crear instancias de nuestro Subject Under Test, gracias a lo cual podemos controlar más fácilmente los parámetros de creación si los hubiese.

\n\n

En el próximo capítulo añadiremos comportamientos que nos permitirán hacer cosas interesantes con nuestra Collection y trataremos de hacerlo de manera interesante también.

\n\n\n

TDD en PHP. Un ejemplo con colecciones (2)

\n\n

Ahora que tenemos una clase Collection a la que podemos añadir objetos de un tipo determinado o sus descendientes, vamos a desarrollar algo de comportamiento. Al fin y al cabo, queremos nuestras colecciones para hacer algo con sus elementos, no sólo para admirarlas.

\n\n

Testing dirigido por Checklist

\n\n

Antes de continuar con el desarrollo, voy a detenerme en una cuestión práctica: la checklist de tests.

\n\n

En el libro de TDD by Example, Kent Beck recomienda utilizar una lista de control para ir anotando en ella todas las cosas que queremos testear, tanto las que pensamos a priori, como las que vayan surgiendo a medida que avanzamos en el trabajo.

\n\n

El mejor soporte para esto es papel y lápiz. En último término es una especie de backlog de las especificaciones que queremos cubrir con tests. Cada vez que completamos una tarea la tachamos y seleccionamos la que nos parezca más propicia para realizar a continuación.

\n\n

Además, si nos surge alguna idea de algo que deberíamos probar, lo anotamos y nos olvidamos temporalmente del asunto. Lo mismo si, al repasar la lista, observamos que hay algún asunto que podríamos reformular de algún modo.

\n\n

Esta era nuestra lista inicial:

\n\n

Poder añadir elementos a la colección
Que estos elementos sean objetos
Que pueda decirnos cuántos objetos está almacenando
Que sólo pueda añadir objetos de la misma clase o interfaz
Que pueda añadir objetos de subclases de la original
Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)

\n\n

Y esta es la lista al final del artículo anterior:

\n\n

Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)

\n\n

Filosofía de las colecciones

\n\n

LLegados a este punto debo hablar un poco de lo que tengo en mente sobre las colecciones.

\n\n

Un primer enfoque tiene que ver con las estructuras de datos tradicionales. Algunas librerías de Colecciones ofrecen colas, pilas, heaps y demás. Sin embargo, de momento no estoy interesado en usarlas, ya que mi objetivo es más bien el manejo de colecciones con las que pueda:

\n\n

accionar todos los elementos.
filtrar elementos conforme a un criterio para obtener un subconjunto de la colección.
agregar datos (recuento, etc).
extraer información de todos los elementos de la colección.

\n\n

Así que voy más bien en la línea de poder recorrer los elementos de las colecciones, para lo cual PHP me ofrece diversos recursos, como implementar las interfaces de Iterator y Traversable, de modo que pueda utilizar mis colecciones con foreach y otros bucles. Pero ¿por qué no hacer que sean las propias colecciones las que se ocupen de sus propios elementos?

\n\n

Esto está influenciado por algunos artículos y screencasts de Adam Wathan, autor del libro Refactoring to collections, en el que explica cómo evolucionar el código en estilo imperativo hacia un estilo funcional, eliminado bucles y condicionales gracias al uso de colecciones y “pipelines” de colecciones.

\n\n

Algunas de las piezas necesarias existen en PHP, como las funciones array_map, array_reduce o array_filter, que nos permiten escribir en estilo funcional lo que, de otra manera haríamos mediante bucles foreach.

\n\n

En otros lenguajes, sin embargo, los arrays son objetos e incorporan este tipo de métodos, como es el caso de Javascript o Java, y esto es algo que me gustaría reproducir en este proyecto.

\n\n

Así que podríamos comenzar por each.

\n\n

Implementar el método `each`\n

\n\n

Volvamos a nuestra lista de tareas:

\n\n

Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)

\n\n

Como se puede ver, cada una de los requerimientos de esta lista está asociado con un método específico, orientado a realizar las manipulaciones deseadas en los elementos de la colección.

\n\n

Por otro lado, antes he mencionado los pipelines, vamos a comentar brevemente sobre ellos. En pocas palabras, los pipelines consisten en componer una serie de operaciones sobre un conjunto de datos de modo que cada una se ejecute con los resultados de la anterior. Una forma elegante de expresar eso en código es hacer que cada operación devuelva un objeto del mismo tipo, que soporte las mismas operaciones.

\n\n

Como esto me interesa, lo añado a la lista:

\n\n

Que pueda iterar a través de todos los elementos y hacer algo con ellos (each)
Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder encadenar operaciones

\n\n

Y, ahora, centrémonos en <code>each</code>.

\n\n

Lo que queremos es poder decirle a la colección que los elementos de la lista hagan algo, pero este algo no devolverá resultados. ¿Cómo podemos testear esto?

\n\n

El método each tiene que aceptar un Callable que tome un objeto del tipo coleccionado como argumento, recorrer la lista de elementos y ejecutar el callable con cada uno.

\n\n

Una forma de testear esto podría ser añadir algunos elementos a la lista y definir una función que simplemente se ejecute una vez por cada elemento. Suena un poco “sucio”, pero podría servir.

\n\n

Pero en realidad, hay un test que debo realizar antes: una Collection vacía no debería ejecutar nada. Esta es mi primera tentativa en CollectionTest.php (sólo incluyo la parte relevante):

\n\n

1     public function testEachShouldDoNothingOnEmptyCollection()\n2     {\n3         $sut = $this->getCollection();\n4         $log = '';\n5         $sut->each(function() use (&$log) {\n6             $log .= '*';\n7         });\n8         $this->assertEquals('', $log);\n9     }\n

\n\n\n\n

Lo primero es hacerme con una instancia de Collection mediante el método getCollection que, como quizá recordéis, utilizaba la técnica de Self-shunt, de modo que la propia clase CollectionTest actúa como elemento coleccionable.

\n\n

Para poder registrar su actividad, paso por referencia una variable $log en la que iré acumulando un asterisco por cada ejecución. En este primer test no debería ocurrir nada.

\n\n

Ejecutamos el test y falla, lo que nos indica la necesidad de implementar un método <code>each</code>, que debería aceptar un Callable.

\n\n

1     public function each(Callable $function)\n2     {\n3     }\n

\n\n\n\n

Ahora el test pasa. Estamos en verde, hay que pensar otro test, ahora con, al menos, un elemento.

\n\n

 1     public function testEachShouldIterateOnOneElement()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $log = '';\n 6         $sut->each(function() use (&$log) {\n 7             $log .= '*';\n 8         });\n 9         $this->assertEquals('*', $log);\n10     }\n

\n\n\n\n

Este test, como era de esperar, falla. Así que implementemos lo mínimo posible: ejecutar una vez la función.

\n\n

1     public function each(Callable $function)\n2     {\n3         $function();\n4     }\n

\n\n\n\n

Lanzamos el test y pasa, pero ahora se rompe el test anterior. Y esto es bueno, nos dice que hay que implementar algo. Podríamos implementar ya la iteración, pero vamos a esperar un poco:

\n\n

1     public function each(Callable $function)\n2     {\n3         if ($this->count() > 0) {\n4             $function();\n5         }\n6     }\n

\n\n\n\n

Con esto nos ponemos en verde.

\n\n

El motivo de hacer este baby step es el siguiente: si implementamos la iteración con un sólo elemento, nuestro siguiente test sería irrelevante y no nos iba a aportar información nueva.

\n\n

Por otro lado podría ocurrir que tanto el caso “0 elementos” como el “1 elemento” fuesen especiales (no dejan de ser casos límite al hablar de colecciones) y tener tests específicos para ellos podría desvelar esa peculiaridad.

\n\n

En nuestro ejemplo es previsible que la solución general funcione también para los casos de 0 y 1 elementos, pero para eso, nada mejor que hacer un nuevo test y ver qué pasa:

\n\n

 1     public function testEachShouldIterateTwoElements()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $sut->append($this);\n 6         $log = '';\n 7         $sut->each(function() use (&$log) {\n 8             $log .= '*';\n 9         });\n10         $this->assertEquals('**', $log);\n11     }\n

\n\n\n\n

El test, como era de esperar, no pasa. Toca añadir código de producción:

\n\n

Dos elementos ya son una colección, así que vamos a implementar la iteración, de una forma bien sencilla:

\n\n

1     public function each(Callable $function)\n2     {\n3         foreach ($this->elements as $element) {\n4             $function();\n5         }\n6     }\n

\n\n\n\n

El nuevo test ha pasado, pero se ha roto el test de la colección vacía. Tenemos que tratar este caso límite.

\n\n

1     public function each(Callable $function)\n2     {\n3         if (!$this->count()) {\n4             return;\n5         }\n6         foreach ($this->elements as $element) {\n7             $function();\n8         }\n9     }\n

\n\n\n\n

Y con esto hemos vuelto a verde.

\n\n

Podríamos generalizar este test para recorrer un número arbitrario de elementos, pero lo voy a obviar ya que podemos afirmar que each ejecuta la función tantas veces como elementos hay en la colección.

\n\n

En cambio, quiero detenerme en una situación que no hemos testeado todavía: que la función pasada al método each recibe el elemento correspondiente a la iteración. Todavía no hemos demostrado que eso ocurra. De hecho, hemos utilizado para el test, una función que no recibe parámetros. Necesitamos una nueva que pueda recibir el parámetro.

\n\n

 1     public function testEachShouldPassEveryElementToCallable()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $sut->append($this);\n 6         $log = '';\n 7         $sut->each(function(CollectionTest $element) use (&$log) {\n 8             $log .= '*';\n 9         });\n10         $this->assertEquals('**', $log);\n11     }\n

\n\n\n\n

Ya hemos testeado la iteración, así que ahora nos centramos en el simple hecho de que cada elemento de la Colección sea pasado a la función. Por tanto, es lo único que vamos a comprobar. A decir verdad, ni siquiera tenemos que hacer nada con el elemento ya que la declaración de la función nos obliga a pasarle un objeto de tipo CollectionTest. las funciones que vayamos a querer usar necesitarán sus propios tests.

\n\n

En fin, como el pase del parámetro no está implementado el test falla.

\n\n

El cambio es simple:

\n\n

1     public function each(Callable $function)\n2     {\n3         if (!$this->count()) {\n4             return;\n5         }\n6         foreach ($this->elements as $element) {\n7             $function($element);\n8         }\n9     }\n

\n\n\n\n

Volvemos a verde. Podríamos pensar en refactorizar. Por una parte, nuestro objetivo con el método each es encapsular el funcionamiento de foreach, siendo la función que pasamos el código que estaría dentro del bucle. Por otra parte, podríamos usar una de las funciones de array de PHP, como por ejemplo:

\n\n

1     public function each(Callable $function)\n2     {\n3         if (!$this->count()) {\n4             return;\n5         }\n6         array_map($function, $this->elements);\n7     }\n

\n\n\n\n

Y esto resulta deliciosamente conciso.

\n\n

Recapitulando `each`\n

\n\n

Debo confesar que al empezar a escribir el capítulo no las tenía todas conmigo respecto a la posibilidad de testear como es debido tanto el tema de pasar un callable y registrar sus efectos sin complicar en exceso los tests.

\n\n

Al final, con pequeños pasos, hemos podido implementar each en nuestra clase Collection.

\n\n

La lista de tareas, queda así, eliminando la que acabamos de terminar:

\n\n

Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder encadenar operaciones

\n\n

Ahora bien, al examinar el último punto me vienen a la cabeza algunas cuestiones: ¿deberían ser las colecciones objetos inmutables? Por ejemplo, en el caso de each si la acción que se ejecuta en el objeto lo modifica de algún modo, ¿debemos realizarlo sobre una copia y devolver ésta?

\n\n

En otros métodos en los que nos interesa devolver otro objeto Collection con los elementos seleccionados o transformados, es posible que nos interese poder alimentar la colección mediante un array de objetos adecuados.

\n\n

Además, existen una serie de método que podrían ser útiles para conocer el estado de la lista (isEmpty), para comprobar si cierto elemento existe en ella o incluso para obtener un elemento según ciertos criterios. Así que nuestro checklist vuelve a crecer:

\n\n

Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder encadenar operaciones
Devolver la colección o la colección generada para poder encadenar operaciones
Considerar la cuestión de la inmutabilidad
Alimentar una lista a partir de un array
Método isEmpty que nos diga si la colección está vacía

\n\n\n

TDD en PHP. Un ejemplo con colecciones (3)

\n\n

Veamos como está nuestra lista de tareas:

\n\n

Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder encadenar operaciones
Devolver la colección o la colección generada para poder encadenar operaciones
Considerar la cuestión de la inmutabilidad
Alimentar una lista a partir de un array
Método isEmpty que nos diga si la colección está vacía

\n\n

Una cosa que no he reflejado en esta lista es que debería poder pedirle objetos concretos a Collection, bien sea por un criterio, bien por su posición. Así que añado estas tareas.

\n\n

Que pueda devolver un array de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder encadenar operaciones
Devolver la colección o la colección generada para poder encadenar operaciones
Considerar la cuestión de la inmutabilidad
Alimentar una lista a partir de un array
Método isEmpty que nos diga si la colección está vacía
Método para obtener uno o más objetos de la lista, por criterio, posición, etc.

\n\n

Fíjate que estoy mezclando diversos tipos de ideas más o menos concretas. Esto es lo de menos porque la iremos reescribiendo continuamente. Pero aquello que está en la checklist está fuera de nuestra cabeza y, por lo tanto, nos deja más recursos para trabajar en la tarea concreta que tengamos entre manos.

\n\n

Pipeline en el método each

\n\n

Al final del capítulo anterior quedaba implementado el método each, pero como nos hemos planteado la posibilidad de poder montar pipelines me gustaría abordarlo ahora antes de entrar a trabajar con otros métodos.

\n\n

En líneas generales, necesitamos resolver dos cosas:

\n\n

Que el método devuelva un objeto Collection para poder aplicarle los mismos métodos.
Si el objeto Collection va a ser inmutable con respecto al método each y devolverá un Collection nuevo con las modificaciones aplicadas.

\n\n

El primer punto es casi trivial y muy fácil de testear. Simplemente esperamos que each devuelva un objeto del tipo Collection.

\n\n

 1     public function testEachShouldAllowPipelining()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $log = '';\n 6         $result = $sut->each(function(CollectionTest $element) use (&$log) {\n 7             $log .= '*';\n 8         });\n 9         $this->assertInstanceOf(Collection::class, $result);\n10     }\n

\n\n\n\n

El test no pasa, pero la implementación es sencilla:

\n\n

1     public function each(Callable $function)\n2     {\n3         if (!$this->count()) {\n4             return;\n5         }\n6         array_map($function, $this->elements);\n7         \n8         return $this;\n9     }\n

\n\n\n\n

Y nos ponemos en verde enseguida.

\n\n

Pero, ¿y si la colección está vacía?

\n\n

1     public function testEachShouldAllowPipeliningOnEmptyCollection()\n2     {\n3         $sut = $this->getCollection();\n4         $log = '';\n5         $result = $sut->each(function(CollectionTest $element) use (&$log) {\n6             $log .= '*';\n7         });\n8         $this->assertInstanceOf(Collection::class, $result);\n9     }\n

\n\n\n\n

Pues pasa que el test falla dado que estamos devolviendo null. Hacer algo con una colección vacía no tiene mucho sentido, pero tal vez no nos interese romper el pipeline, por lo que simplemente devolvemos la misma colección.

\n\n

1     public function each(Callable $function)\n2     {\n3         if (!$this->count()) {\n4             return $this;\n5         }\n6         array_map($function, $this->elements);\n7         \n8         return $this;\n9     }\n

\n\n\n\n

Lo anterior es un ejemplo de la problemática de escoger bien el primer test que hacemos. En each comenzamos por una colección vacía, y al ir avanzando con nuevos tests, descubrimos que ese era un caso límite para el problema que estamos tratando puesto que al ir evolucionando la implementación llega un momento en que ese test falla.

\n\n

En esta ocasión, al “saltarnos” la situación de colección vacía no hemos detectado el caso límite, sino que lo hemos tenido que pensar nosotros. Por eso, es conveniente detenerse a pensar un poco más el test inicial más sencillo posible.

\n\n

De momento, no voy a tachar nada de mi lista para recordar este tema al implementar otros métodos.

\n\n

Una digresión: mutable, modificable o todo lo contrario

\n\n

La verdad es que llevo un buen rato dándole vueltas a este tema. En algunos lenguajes, como Scala, se ofrecen colecciones inmutables y mutables. Cada tipo tiene sus ventajas e inconvenientes. El que una colección sea inmutable no implica que no podamos realizar operaciones con ella, pero estas operaciones devolverán una colección nueva, que es copia de la original y a la cual se le aplica la transformación. De este modo, la colección original permanece inalterada.

\n\n

La mutabilidad o inmutabilidad no afecta a la interfaz. Sencillamente en una colección inmutable los métodos clonan la colección actual y aplican la transformación sobre ella.

\n\n

Hay varias cuestiones con respecto a la mutabilidad y la inmutabilidad de la colección:

\n\n

Que se puedan, o no, añadir, quitar o cambiar elementos a la colección, una vez creada. En algunos casos, necesitamos que la colección funcione como si fuese un repositorio en memoria. En otros, nos interesa una colección constante de la que obtener ciertos datos. Una colección que no se pueda modificar en este sentido, no expone métodos append o remove o, si lo hace, estos devuelven una instancia nueva de la colección.
Que ciertas operaciones devuelvan la colección transformada o bien una colección nueva con la transformación. Una operación de filtrado siempre debería devolvernos una colección nueva, dejando la original intacta, para poder realizar nuevas búsquedas o selecciones en ella.
Que se puedan modificar elementos o no, en el sentido de cambiar el estado de los elementos, pero no la colección como tal. El hecho de que la colección no pueda variar el número de elementos no implica que éstos no puedan cambiar de algún modo. El método each, implementado en el artículo anterior, encaja aquí.

\n\n

Es buena idea leerse este artículo de Martin Fowler sobre las collection pipelines. Además, nos da un montón de pistas sobre qué funcionalidad añadir en ella.

\n\n

Fin de la digresión.

\n\n

Antes de implementar el método map

\n\n

La idea de map es aplicar una transformación a cada elemento de la colección actual y creando una nueva colección con los resultados de esa transformación. Collection es inmutable con respecto a map y tampoco los objetos deberían ver su estado cambiado.

\n\n

En cierto modo, map es lo mismo que each, pero devolviendo resultados.

\n\n

Un problema que nos plantea map tiene que ver con lo que devuelve. Si queremos poder hacer pipelines, debería devolver un objeto Collection (en principio nos da igual qué objetos colecciona), por lo que vamos a necesitar poder crearlo a partir de arrays de objetos. Eso es algo que habíamos puesto en nuestra lista de tareas, en el apartado de ideas a considerar, pero que ahora lo vamos a reformular.

\n\n

Además, me estoy fijando que hay algunas ideas que no están bien expresadas y que incluso entran en contracción, como que el método map devuelva un array, cuando quiero que devuelva un Collection y así poderlo encadenar.

\n\n

Sin embargo, hay una cuestión que me preocupa: ¿y si no devuelvo objetos en la función de mapeo? Por ejemplo, a lo mejor sólo quiero obtener una lista simple de nombres a partir de una colección de objetos.

\n\n

Una solución es forzar que todas las transformación den como resultado objetos, que no tienen que ser del mismo tipo que los de la colección original, de modo que pueda coleccionarlos sin más. Eso me lleva a pensar en que podría ser necesario un método mapToArray o toArray (o ambos), con el que mapear una colección a un array y que sería el punto final de un pipeline.

\n\n

Otra solución sería generalizar Collection para permitir cualquier tipo de dato, de modo que pueda coleccionar cualquier cosa. Esta idea es correcta y es interesante. Podríamos poder seguir especificando el tipo para garantizar que la lista se mantenga coherente. Aún siguiendo este desarrollo, sigue siendo interesante incluir el método mapToArray para poder obtener la colección en ese formato que suele ser útil para interactuar con otro código existente.

\n\n

¿Cuál de las dos elegir? Pues da un poco igual. Como estamos desarrollando con TDD estamos protegidos para realizar cualquier cambio, no sólo refactoring, sino también cambios de funcionalidad. Mi opción va a ser la primera (sólo Objetos) y luego, ya veremos. Lo anoto para no olvidarlo, además de reorganizar un poco la lista conforme a las reflexiones que he estado haciendo:

\n\n

Que pueda devolver una Collection de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder crear una Collection a partir de un array de objetos
Devolver la colección o la colección generada para poder encadenar operaciones
Considerar la cuestión de la inmutabilidad
Método isEmpty que nos diga si la colección está vacía
Método para obtener uno o más objetos de la lista, por criterio, posición, etc.
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array

\n\n

Ahora sí, ahora vamos con map

\n\n

Implementando map

\n\n

Repasemos lo que sabemos sobre map:

\n\n

Tiene que devolver Collection
Tiene que aceptar un callable
Este callable tiene que devolver objetos coleccionables, que no tienen por qué ser del mismo tipo que los coleccionables

\n\n

Así que tendremos que probar eso.

\n\n

El caso más sencillo sería el de la colección vacía, como hemos dicho antes, no queremos romper el pipeline, por lo que el test podría ser el siguiente:

\n\n

1     public function testMapShouldAllowPipelineOnEmptyCollection)\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->map(function(CollectionTest $element) {\n5             return $element;\n6         });\n7         $this->assertInstanceOf(Collection::class, $result);\n8     }\n

\n\n\n\n

Obviamente, el test va a fallar porque no tenemos método map. Lo creamos y pasamos de nuevo el test para ver que falla. Después haremos la implementación más sencilla posible, que es devolver la misma colección.

\n\n

1     public function map(Callable $function) : Collection\n2     {\n3         return $this;\n4     }\n

\n\n\n\n

Y esto nos coloca en verde de nuevo.

\n\n

Ocurre, sin embargo, que no queremos que map devuelva la misma Collection, sino otra. Así que necesitamos un test que pruebe eso:

\n\n

1     public function testMapShouldReturnAnotherCollection()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->map(function(CollectionTest $element) {\n5             return $element;\n6         });\n7         $this->assertNotSame($sut, $result);\n8     }\n

\n\n\n\n

El test falla porque devolvemos la misma colección, vamos a ver cómo solucionar eso de momento:

\n\n

1     public function map(Callable $function) : Collection\n2     {\n3         return clone $this;\n4     }\n

\n\n\n\n

Ahora que estamos en verde, haremos un test para probar que se realiza el mapeo. Para ello añadimos un elemento a la colección y esperamos que la colección devuelta tenga un elemento. Por desgracia, este test va a pasar:

\n\n

1     public function testShouldMapSingleElement()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $result = $sut->map(function(CollectionTest $element) {\n6             return $element;\n7         });\n8         $this->assertEquals(1, $result->count());\n9     }\n

\n\n\n\n

He puesto este test como ejemplo de test mal escogido. La información que devuelve no nos aporta nada porque no chequea que el cambio deseado se produzca. Aunque la medida es compatible con lo que esperamos (una colección con un elemento), tal y como la recogemos no nos permite discriminar nada.

\n\n

Lo mejor sería que la función que pasamos a map devuelva un objeto distinto y chequear que la nueva colección maneja objetos de ese tipo.

\n\n

Así que creamos un objeto simple para este propósito:

\n\n

1 class MappedObject {}\n

\n\n\n\n

Y cambiamos el test:

\n\n

1     public function testShouldMapSingleElement()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $result = $sut->map(function(CollectionTest $element) {\n6             return new MappedObject();\n7         });\n8         $this->assertAttributeEquals(MappedObject::class, 'type', $result);\n9     }\n

\n\n\n\n

Estamos chequeando un estado privado del objeto $result, que sabenos que es del tipo Collection por los tests anteriores. Siendo estrictos no deberíamos chequear propiedades privadas, aunque creo que hay situaciones en las que por pragmatismo es mejor hacerlo. Por otro lado, poder obtener el tipo de objeto de una colección sería razonable, así que podríamos añadir a la lista esa característica.

\n\n

Que pueda devolver una Collection de transformaciones de los objetos (map)
Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder crear una Collection a partir de un array de objetos
Devolver la colección o la colección generada para poder encadenar operaciones
Considerar la cuestión de la inmutabilidad
Método isEmpty que nos diga si la colección está vacía
Método para obtener uno o más objetos de la lista, por criterio, posición, etc.
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método getType devuelve tipo de la colección

\n\n

En cualquier caso, ahora hemos conseguido un test que falla, con lo que estamos listos para implementar.

\n\n

1     public function map(Callable $function) : Collection\n2     {\n3         return self::of(MappedObject::class);\n4     }\n

\n\n\n\n

Ahora el test pasa, pero no prueba que estemos mapeando, sólo prueba que devolvemos una Collection con el tipo MappedObject, el objeto resultado del mapeo. Nuestro test necesita una cierta triangulación, es decir, varias aserciones que, juntas, prueben lo que queremos mostrar con el test. Debemos volver al rojo, retomando un test que descartamos antes:

\n\n

 1     public function testShouldMapSingleElement()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $result = $sut->map(function(CollectionTest $element) {\n 6             return new MappedObject();\n 7         });\n 8         $this->assertAttributeEquals(MappedObject::class, 'type', $result);\n 9         $this->assertEquals(1, $result->count());\n10     }\n

\n\n\n\n

Ahora ya tenemos mejor información. La implementación mínima es la siguiente:

\n\n

1     public function map(Callable $function) : Collection\n2     {\n3         $mapped = self::of(MappedObject::class);\n4         $mapped->append(new MappedObject());\n5         return $mapped;\n6     }\n

\n\n\n\n

Hemos vuelto a verde, pero hay una cosa que me enciende una pequeña luz de alarma. Los tests con colecciones vacías no fallan aunque nuestra implementación actual fuerza a devolver una colección con un objeto. Necesitamos un test que verifique que devolvemos una nueva colección vacía:

\n\n

1     public function testMapShouldReturnNewEmptyCollectionOnEmptyCollection()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->map(function(CollectionTest $element) {\n5             return $element;\n6         });\n7         $this->assertInstanceOf(Collection::class, $result);\n8         $this->assertEquals(0, $result->count());\n9     }\n

\n\n\n\n

Creamos una implementación que contemple este caso límite:

\n\n

1     public function map(Callable $function) : Collection\n2     {\n3         if (!$this->count()) {\n4             return clone $this;\n5         }\n6         $mapped = self::of(MappedObject::class);\n7         $mapped->append(new MappedObject());\n8         return $mapped;\n9     }\n

\n\n\n\n

Nos vamos acercando, estamos de nuevo en verde. Necesitamos un test más que nos fuerce a implementar una solución más general:

\n\n

 1     public function testShouldMapTwoElements()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $sut->append($this);\n 6         $result = $sut->map(function(CollectionTest $element) {\n 7             return new MappedObject();\n 8         });\n 9         $this->assertAttributeEquals(MappedObject::class, 'type', $result);\n10         $this->assertEquals(2, $result->count());\n11     }\n

\n\n\n\n

Este test ya hace fallar nuestra implementación obvia, ahora toca encontrar una solución que sea general.

\n\n

Para crear nuestra colección necesitamos determinar el tipo de los objetos devueltos por nuestra función de transformación aplicada sobre los objetos existentes en la colección. Una forma más o menos económica es usar el primer elemento para obtener esa información, crear la colección y empezar a poblarla. Luego seguimos el resto de elementos hasta el final. Aquí tenemos una primera implementación, que hace que el test pase:

\n\n

 1     public function map(Callable $function) : Collection\n 2     {\n 3         if (!$this->count()) {\n 4             return clone $this;\n 5         }\n 6         $firstMapping = $function(reset($this->elements));\n 7         $mapped = self::of(get_class($firstMapping));\n 8         $mapped->append($firstMapping);\n 9         while ($object = next($this->elements)) {\n10             $mapped->append($function($object));\n11         }\n12         return $mapped;\n13     }\n

\n\n\n\n

Y como el código es poco inteligible, vamos a refactorizar un poco aprovechando que estamos en verde:

\n\n

 1     public function map(Callable $function) : Collection\n 2     {\n 3         if (!$this->count()) {\n 4             return clone $this;\n 5         }\n 6         $mapped = $this->instanceCollection($function);\n 7         while ($object = next($this->elements)) {\n 8             $mapped->append($function($object));\n 9         }\n10         return $mapped;\n11     }\n12 \n13     protected function instanceCollection(Callable $function): Collection\n14     {\n15         $firstMapping = $function(reset($this->elements));\n16         $mapped = self::of(get_class($firstMapping));\n17         $mapped->append($firstMapping);\n18         return $mapped;\n19     }\n

\n\n\n\n

Para finalizar (por ahora)

\n\n

Al igual que ocurre con each, no hay razón para pensar que haya otros casos límite con colecciones de más de dos elementos, por lo que no merece la pena escribir tests para probar que podemos mapear colecciones más grandes.

\n\n

Nos quedan unas cuantas cosas pendientes en la lista de tareas, pero las afrontaremos en futuras entregas.

\n\n

Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder crear una Collection a partir de un array de objetos
Devolver la colección o la colección generada para poder encadenar operaciones
Considerar la cuestión de la inmutabilidad
Método isEmpty que nos diga si la colección está vacía
Método para obtener uno o más objetos de la lista, por criterio, posición, etc.
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método getType devuelve tipo de la colección

\n\n\n

TDD en PHP. Un ejemplo con colecciones (4)

\n\n

En este capítulo voy a intentar desarrollar el método filter, el cual también nos dará un punto de partida para otros métodos.

\n\n

Y nuestra lista de tareas había quedado así:

\n\n

Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda agregar la Collection (reduce)
Poder crear una Collection a partir de un array de objetos
Devolver la colección o la colección generada para poder encadenar operaciones
Considerar la cuestión de la inmutabilidad
Método isEmpty que nos diga si la colección está vacía
Método para obtener uno o más objetos de la lista, por criterio, posición, etc.
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método getType devuelve tipo de la colección

\n\n

Antes de nada, voy a hacer un poco de limpieza en la lista.

\n\n

Los puntos de devolver la colección para hacer pipelines y el tema de la inmutabilidad están más o menos recogidos en las implementaciones que hemos hecho hasta ahora y lo cierto es que la que vamos a afrontar ahora (la del método filter) lo implica claramente, así que las voy a tachar de la lista.

\n\n

Por otro lado, voy a reorganizarla un poco para poner cerca cuestiones que son similares. Finalmente, la lista queda así:

\n\n

Que pueda devolver una Collection de objetos filtrados conforme a un criterio (filter)
Que pueda obtener uno o más objetos de la lista, por criterio, posición, etc.
Que pueda agregar la Collection (reduce)
Poder crear una Collection a partir de un array de objetos
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método isEmpty que nos diga si la colección está vacía
Método getType devuelve tipo de la colección

\n\n

Estos artículos van de TDD más que de Collections

\n\n

A estas alturas debería estar claro que lo que me importa de estos artículos es más el aprendizaje de la metodología TDD que la creación de una biblioteca de Collections. La biblioteca puede ser útil per se y podríamos hablar de ello en otro artículo, pero para mí esta serie es algo parecido a una kata con la que mejorar mis habilidades como desarrollador que utiliza TDD siempre que puede.

\n\n

En realidad, a medida que profundizo en este proyecto, me doy cuenta de la capacidad de TDD para aprender a programar mejor y para conseguir mejores diseños de software:

\n\n

La metodología te va guiando paso por paso: no importa lo complejo que pueda ser el problema porque lo estás dividiendo en trozos muy pequeños y manejables.
Cada fragmento del problema acaba teniendo una implementación cuya dificultad oscila entre lo obvio y los sencillo. Si la implementación es complicada, es porque seguramente estamos testeando algo que no debemos o no estamos desmenuzando bien el problema.
El ciclo test mínimo que falle - implementación mínima para pasar el test te permite no agobiarte tratando de mantener una imagen completa del problema en la cabeza. Vas dando pequeños pasos y, cuando te das cuenta, has llegado al final sin cansarte.
Y cuando llegas al final tienes un producto que funciona, que posiblemente no de grandes problemas de integración (y si los da, puedes crear nuevos tests para probarlos) y que tiene una cobertura de tests del 100%, por lo que cualquier regresión se manifestará enseguida.

\n\n

Pero vamos al lío, que es para lo que estamos aquí.

\n\n

Filtrando una colección

\n\n

Cuando tenemos una colección de objetos suele interesarnos poder realizar búsquedas y selecciones en base a algún criterio, así que vamos a implementar eso en nuestra clase Collection.

\n\n

Fíjate que tenemos dos situaciones:

\n\n

En unos casos queremos conseguir todos los objetos de la colección que cumplen el criterio, que es lo que entendemos como una búsqueda o un filtrado, y que nos devolverá una nueva colección que contenga los objetos seleccionados (o ninguno, si ninguno cumple los criterios).
En otros casos queremos obtener sólo un elemento que cumpla las condiciones. En ese caso, devolverá un objeto del tipo contenido en la colección si es que alguno cumple los criterios. En caso de que no los cumpla puede no devolver nada, puede devolver un objeto nulo o puede lanzar una excepción si partimos del supuesto de que el objeto debería estar ahí.

\n\n

Ambas situaciones son parecidas, pero no exactamente iguales. Por el momento, nos vamos a centrar en la primera: crear un método filter que nos devuelva una colección de objetos seleccionados por un criterio.

\n\n

La idea es que el método filter reciba una función booleana que devuelva true si el objeto cumple los criterios y false si no los cumple. En el primer caso, lo añadiremos a la nueva colección. Al terminar de revisar todos los elementos devolvemos la colección que haya resultado. Obviamente esta colección será del mismo tipo que aquella sobre la que operamos.

\n\n

Aprovechando lo que hemos aprendido hasta ahora, sabemos que el test más sencillo con el que podemos empezar es el de la colección vacía, que devolverá una colección vacía, que será del mismo tipo que la original y que, además, no ha de ser el mismo objeto. Esto son cuatro tests:

\n\n

Filter devuelve un objeto Collection
El tipo de objeto que maneja es el mismo de la Collection original
La Collection devuelta no tiene elementos
La Collection devuelta no es la misma que la original

\n\n

Podemos adoptar dos enfoques. Hasta ahora, hemos escrito un test para probar cada una de estas condiciones, con una aserción por test. Alternativamente podríamos escribir un sólo test con las cuatro aserciones.

\n\n

¿Qué es mejor? La primera opción nos dará una información más explícita si al ir implementando hacemos fallar alguno de estos tests, pues nos señala claramente dónde hemos metido la pata. La segunda opción nos permite avanzar un poco más rápido si tenemos confianza en lo que estamos haciendo o simplemente nos parece que podemos tratar el problema como un todo. A cambio perdemos un poco de resolución: en caso de que falle el test, todavía tendremos que examinar cuatro aserciones para descubrir qué hemos roto.

\n\n

Yo voy a optar por la primera y dar pasos más cortos.

\n\n

Mi primer test mínimo prueba que filter devuelve un objeto Collection:

\n\n

1     public function testFilterShouldReturnACollection()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->filter(function(CollectionTest $element) {\n5             return false;\n6         });\n7         $this->assertInstanceOf(Collection::class, $result);\n8     }\n

\n\n\n\n

El test fallará puesto que no existe el método filter y volverá a fallar al proponer una implementación vacía.

\n\n

1     public function filter(Callable $function)\n2     {\n3     }\n

\n\n\n\n

De momento, nos bastará retornar la propia Collection para volver a verde. Sí, ya sé que esa es una de las cosas que no queremos hacer, pero dejemos que nos lo pida un test más adelante. No anticipemos los problemas pues esa prisa es la que nos va a llevar a crear mal código.

\n\n

1     public function filter(Callable $function)\n2     {\n3         return $this;\n4     }\n

\n\n\n\n

Ahora que estamos en verde y que no hay implementación más sencilla posible, vayamos al siguiente punto, que es el que trata sobre el tipo de objeto de la lista. Nos damos cuenta de que ese test no nos va a servir de nada, al menos no en este momento, así que lo dejaremos para el final. ¿Por qué sabemos que no nos va a servir de nada? Pues porque ese test va a pasar a la primera ya que estamos devolviendo el mismo objeto Collection sobre el que operamos. Y lo mismo ocurre con el siguiente (la colección devuelta está vacía).

\n\n

Lo que necesitamos siempre para avanzar es un test que falle y eso nos lleva al punto cuatro: la Collection no es la misma que la original. Este tests sí va a fallar, obligándonos a introducir un cambio en la implementación suficiente para pasar:

\n\n

1     public function testFilterShouldReturnNewCollection()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->filter(function(CollectionTest $element) {\n5             return false;\n6         });\n7         $this->assertNotSame($sut, $result);\n8     }\n

\n\n\n\n

Bien. El test falla, así que toca implementar algo.

\n\n

1     public function filter(Callable $function)\n2     {\n3         return Collection::of(\\stdClass::class);\n4     }\n

\n\n\n\n

No hay que complicarse mucho, creamos una lista nueva y como hemos de asignarle un tipo de objeto tiramos del que tenemos más cerca, el tipo de la clase que contiene el método o, como en el ejemplo, de stdClass, la clase básica de PHP.

\n\n

Ahora volvemos a los puntos que hemos pospuesto. ¿Podemos hacer un test que falle para probarlos?

\n\n

En el caso comprobar el tipo de objeto, sí que podemos.

\n\n

1     public function testFilterShouldReturnCollectionOfSameType()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->filter(function(CollectionTest $element) {\n5             return false;\n6         });\n7         $this->assertAttributeEquals(CollectionTest::class, 'type', $result);\n8     }\n

\n\n\n\n

Prueba superada. El método filter devuelve una Collection de stdClass y nosotros queremos una de CollectionTest. Por tanto, debemos cambiar la implementación para que podamos volver al verde:

\n\n

1     public function filter(Callable $function)\n2     {\n3         return Collection::of($this->type);\n4     }\n

\n\n\n\n

Y, finalmente, tenemos que probar que la nueva colección creada está vacía. Sin embargo, tal como está la implementación sabemos que el test va a pasar, incluso si añadimos objetos a nuestra colección bajo test: la nueva colección se crea vacía y, de momento, no estamos haciendo nada con ella.

\n\n

Así que el siguiente test mínimo que sí podría fallar es un test en el que añadimos un objeto a la colección bajo test, aplicamos una función que devuelve true, indicando que esos objetos deben incluirse en la selección y esperando que nos devuelva la nueva colección con el objeto incluido.

\n\n

Aquí tenemos el test que prueba lo que acabamos de decir:

\n\n

1     public function testFilterShouldIncludeElementIfCallableReturnsTrue()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $result = $sut->filter(function(CollectionTest $element) {\n6             return true;\n7         });\n8         $this->assertEquals(1, $result->count());\n9     }\n

\n\n\n\n

Este test sí falla y, por tanto, nos obliga a implementar algo.

\n\n

1     public function filter(Callable $function)\n2     {\n3         $filtered = Collection::of($this->type);\n4         $filtered->append(reset($this->elements));\n5         return $filtered;\n6     }\n

\n\n\n\n

El test pasa, pero se nos rompen los tests anteriores. Tenemos una regresión, esperable por otra parte, debido al caso límite de colección vacía, que ya conocemos de la implementación de los otros métodos.

\n\n

Trataremos el caso particular con una cláusula de guarda, sin más.

\n\n

1     public function filter(Callable $function)\n2     {\n3         $filtered = Collection::of($this->type);\n4         if (!$this->count()) {\n5             return $filtered;\n6         }\n7         $filtered->append(reset($this->elements));\n8         return $filtered;\n9     }\n

\n\n\n\n

Ahora, podríamos probar el caso de que la función de filtrado devuelva false. Entonces la colección devuelta por filter no podrá tener elementos. Este test falla:

\n\n

1     public function testFilterShouldNotIncludeElementIfCallableReturnsFalse()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $result = $sut->filter(function(CollectionTest $element) {\n6             return false;\n7         });\n8         $this->assertEquals(0, $result->count());\n9     }\n

\n\n\n\n

Obligándonos a hacer una implementación mínima del filtrado para que el test pase.

\n\n

 1     public function filter(Callable $function)\n 2     {\n 3         $filtered = Collection::of($this->type);\n 4         if (!$this->count()) {\n 5             return $filtered;\n 6         }\n 7         if ($function(reset($this->elements))) {\n 8             $filtered->append(reset($this->elements));\n 9         }\n10         return $filtered;\n11     }\n

\n\n\n\n

Para nuestro siguiente test necesitamos que la lista tenga más de un elemento. En la implementación de los métodos each y map llegamos a la conclusión de que dos elementos serían suficientes para probar que la función funcionaría bien para cualquier tamaño de colección.

\n\n

 1     public function testFilterShouldIterateOverAllElements()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $sut->append($this);\n 6         $result = $sut->filter(function(CollectionTest $element) {\n 7             return true;\n 8         });\n 9         $this->assertEquals(2, $result->count());\n10     }\n

\n\n\n\n

El test falla, ya que la implementación actual sólo añade el primer elemento de la colección, tendríamos que recorrer los elementos y probarlos con la función de filtro.

\n\n

 1     public function filter(Callable $function): Collection\n 2     {\n 3         $filtered = Collection::of($this->type);\n 4         if (!$this->count()) {\n 5             return $filtered;\n 6         }\n 7         foreach ($this->elements as $element) {\n 8             if ($function($element)) {\n 9                 $filtered->append($element);\n10             }\n11         }\n12         return $filtered;\n13     }\n

\n\n\n\n

Finalmente, el test pasa con esta implementación, que pone punto final al desarrollo del método filter.

\n\n

Pero… Nuestro abogado del diablo lleva un rato sugiriendo que deberíamos probar varias condiciones más. Por ejemplo:

\n\n

Que la función de filtro permita probar que unos objetos pasan y otros no pasan (ahora mismo cuando hacemos un test usamos una función que siempre devuelve lo mismo). Realmente no es necesario. Lo que nosotros tenemos que probar es que filter utiliza el resultado de la función para decidir si incluye o no un objeto en la lista, cosa que hemos probado ya con un par de tests. Si la función filtra bien o no, es cuestión del test de la propia función.
Que los objetos de la colección deberían ser instancias distintas (ahora son la misma). Tampoco es necesario, sencillamente no los consideramos en la función de filtro, tan sólo necesitamos que estén llenando la colección en un número conocido.
Que tenemos que probar que estamos iterando la colección. De momento sólo hemos probado que si esperamos un número de elementos (porque se han de incluir o todos o ninguno, según lo que devuelva la función de filtrado), recibiremos ese número de elementos en la colección filtrada, podría ser el mismo elemento repetido el número de veces deseado.

\n\n

Y aquí nos ha sembrado una duda razonable. Como nosotros podemos ver la implementación, estamos razonablemente seguros de que recorremos la colección y que, por tanto, nuestro algoritmo es correcto. Pero, ¿qué haríamos si no supiésemos nada de la implementación? ¿Cómo testeamos eso?

\n\n

En ese caso, tendríamos que introducir instancias diferentes en la colección original y ver si la colección filtrada tiene ambas. En principio, podríamos comprobar si ambas colecciones son iguales (que no la misma).

\n\n

Pero para probar eso no necesitamos hacer otro test, sino arreglar el último que hemos hecho ya que no demuestra que hayamos iterado la colección, siendo ese su objetivo. Creo que nos basta montar la colección con un objeto y con su clon. Y después ver si la colección resultante equivale a la original. No nos hace falta triangular que la colección probada y la filtrada no son la misma instancia, pues es algo que hemos demostrado al principio.

\n\n

Mi apuesta es que el test pasará.

\n\n

 1     public function testFilterShouldIterateOverAllElements()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $sut->append(clone $this);\n 6         $result = $sut->filter(function(CollectionTest $element) {\n 7             return true;\n 8         });\n 9         $this->assertEquals($sut, $result);\n10     }\n

\n\n\n\n

Y lo hace.

\n\n

Ahorrando algunos tests con return type y type hinting

\n\n

La primera regla de TDD dice que lo primero es escribir el test más sencillo posible que falle (y no compilar es fallar). Esto quiere decir que si el test no se puede ejecutar porque hemos cometido un error al escribir la implementación, o aún no la hemos escrito, es lo mismo que decir que el test falla. El error nos dice qué tenemos que hacer.

\n\n

En PHP podemos hacer equivalente no compilar con tener algún tipo de error que impida que el test se ejecute.

\n\n

Eso nos permite evitar escribir unos cuantos tests. Es algo que no he tenido en cuenta mientras escribía estos artículos y me gustaría comentar.

\n\n

En PHP 7, como ocurría hace tiempo con otros lenguajes, ya es posible definir el tipo de retorno de métodos y funciones. Si lo que devuelve el método o función no coincide con el tipo declarado se lanzará un error. Y si estamos escribiendo un test, quiere decir que el test fallará.

\n\n

En la práctica esto significa que realmente no necesitamos escribir tests que prueben explícitamente el tipo que devuelve una función o método: si declaramos el tipo de retorno y no coincide, el intérprete de PHP lanzará un error y cualquier test que pruebe ese código fallará.

\n\n

Por ejemplo, el primer test de filter comprobaba justamente eso:

\n\n

1     public function testFilterShouldReturnACollection()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->filter(function(CollectionTest $element) {\n5             return false;\n6         });\n7         $this->assertInstanceOf(Collection::class, $result);\n8     }\n

\n\n\n\n

Pero usando return type, el test resulta innecesario, ya que el intérprete me obliga a devolver el tipo declarado. Esto es, el siguiente código:

\n\n

1     public function filter(Callable $function) : Collection\n2     {\n3     }\n

\n\n\n\n

No funcionaría porque el intérprete lanza un error, y no se ejecuta el código hasta que devolvemos un Collection, haciendo el test innecesario por redundante. Si más adelante la implementación provocase devolver un objeto que no fuese Collection, el propio intérprete haría fallar todos los tests implicados.

\n\n

Es más, incluso es posible que nuestro test del tipo devuelto sea insuficiente si el método puede tener varios puntos de salida, con la posibilidad de devolver cosas diferentes:

\n\n

1     public function filter(Callable $function)\n2     {\n3 \t\t//...\n4 \t\tif ($someCondition) {\n5 \t\t\treturn new \\stdClass;\n6 \t\t}\n7 \t\treturn Collection::of(\\stdClass::class);\n8     }\n

\n\n\n\n

Este código podría no hacer fallar el test del tipo devuelto si $someCondition no se cumple al ejecutarlo (en el caso de que el test no contemple la posibilidad de que haya varios puntos de retorno), aunque sí podría hacer que fallasen otros.

\n\n

Pero con return type el intérprete fallará en el momento en que el flujo intente retornar por la rama del if, haya o no haya tests que lo comprueben explícitamente.

\n\n

1     public function filter(Callable $function) : Collection\n2     {\n3 \t\t//...\n4 \t\tif ($someCondition) {\n5 \t\t\treturn new \\stdClass;\n6 \t\t}\n7 \t\treturn Collection::of(\\stdClass::class);\n8     }\n

\n\n\n\n

Ocurre lo mismo si hacemos Type hinting en los parámetros de los métodos, incluso de los privados, si el parámetro que se pasa no es del tipo indicado, se lanzará un error y los tests correspondientes fallarán. Eso nos indica, además, que es una buena práctica hacer type hinting en los métodos privados para aumentar la confianza en ese código. Si la implementación cambia en el futuro y deja de respetarse el tipo del parámetro, los tests que ejecuten esa llamada fallarán, alertándonos de una regresión.

\n\n

Los programadores de otros lenguajes fuertemente tipados llevan años disfrutando de esta ventaja y es una práctica que merece la pena adoptar.

\n\n

¿Algo que refactorizar?

\n\n

Ahora que hemos avanzado tanto y que estamos en verde puede ser buen momento para ver si hay algo que podamos refactorizar. Idealmente lo vamos haciendo en cada ciclo red-green-refactor, pero ocurre muchas veces que al revisar un código en otra sesión de trabajo observamos cosas que nos gustaría cambiar.

\n\n

Por ejemplo, en el método map usaba self::of para crear la nueva colección. Creo que Collection::of es mucho más expresivo y es lo que he usado al implementar filter, así que lo he cambiado. Los tests siguen pasando, lo que indica que mi refactor es correcto.

\n\n

Tampoco acaba de convencerme el método protected instanceCollection, ya que hace dos cosas: instancia la nueva colección y le añade el primer elemento. Así que voy a reescribir map para que quede un poco más claro, haciendo innecesaria la extracción de dicho método:

\n\n

 1     public function map(Callable $function) : Collection\n 2     {\n 3         if (!$this->count()) {\n 4             return clone $this;\n 5         }\n 6 \n 7         $first = $function(reset($this->elements));\n 8         $mapped = Collection::of(get_class($first));\n 9         $mapped->append($first);\n10 \n11         while ($object = next($this->elements)) {\n12             $mapped->append($function($object));\n13         }\n14 \n15         return $mapped;\n16     }\n

\n\n\n\n

Volvemos a pasar los tests para asegurarnos de que no rompemos nada.

\n\n

Devolver un objeto

\n\n

Muy relacionado con el método filter estaría el tener un método que nos permite recuperar un elemento de la colección que cumpla un criterio. Al igual que en el método de filtrado, pasaremos una función que encapsule ese criterio.

\n\n

La diferencia es que nuestro nuevo método debe devolver el primer objeto que encuentre cumpliendo el criterio. Le vamos a llamar getBy.

\n\n

En este caso no podemos hacer return type y será necesario comprobar que el objeto recibido es del tipo deseado.

\n\n

El principal problema que nos plantea este método es qué hacer en caso de que no existan elementos de la colección que cumplan los criterios definidos. Las opciones principales son retornar null o lanzar una excepción.

\n\n

En el segundo caso, la excepción expresaría el hecho de que el elemento debería estar y que lo “raro” es que no esté. Esto tiene sentido en ciertas situaciones, por ejemplo, si hacemos una búsqueda de un objeto por su ID, que sabemos que existe. Otro ejemplo es que hayamos ejecutado filter antes y que hayamos extraído los criterios de getBy de los resultados de esa búsqueda.

\n\n

Yo voy a lanzar una excepción, pero en algunas aplicaciones podría tener sentido otra opción, inclusive devolver un objeto nulo.

\n\n

Empecemos por el caso de la colección vacía, que ya sabemos que es un buen test mínimo que falla:

\n\n

1     public function testGetByShouldThrowExceptionWhenCollectionIsEmpty()\n2     {\n3         $sut = $this->getCollection();\n4         $this->expectException(\\UnderflowException::class);\n5         $sut->getBy(function (CollectionTest $element) {\n6             return true;\n7         });\n8     }\n

\n\n\n\n

Y el test falla porque no tenemos implementación de getBy. Hacemos el ciclo habitual: Primero implementación vacía para que no falle el intérprete:

\n\n

1     public function getBy(Callable $function)\n2     {\n3     }\n

\n\n\n\n

Fallo del test y nueva implementación mínima para pasar el test:

\n\n

1     public function getBy(Callable $function)\n2     {\n3         throw new \\UnderflowException('Collection is empty');\n4     }\n

\n\n\n\n

Al volver a verde es hora de pensar un nuevo test mínimo que falle. Si la colección no está vacía y no se encuentra el elemento buscado devolveremos una excepción, pero no del mismo tipo.

\n\n

1     public function testGetByShouldThrowExceptionIfElementIsNotFound()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $this->expectException(\\OutOfBoundsException::class);\n6         $sut->getBy(function (CollectionTest $element) {\n7             return false;\n8         });\n9     }\n

\n\n\n\n

La implementación supone controlar el caso especial de colección vacía:

\n\n

1     public function getBy(Callable $function)\n2     {\n3         if (!$this->count()) {\n4             throw new \\UnderflowException('Collection is empty');\n5         }\n6         throw new \\OutOfBoundsException('Element not found');\n7     }\n

\n\n\n\n

Pero si el objeto está en la colección no debe saltar ninguna excepción y el método devolverá el objeto encontrado. Vamos a probarlo:

\n\n

1     public function testGetByShouldReturnFoundElement()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $result = $sut->getBy(function (CollectionTest $element) {\n6             return true;\n7         });\n8         $this->assertSame($this, $result);\n9     }\n

\n\n\n\n

Y el test falla porque tira la excepción. No está pidiendo a gritos implementar algo, ¿no? La implementación pasa por tener en cuenta el resultado de la función pasada.

\n\n

 1     public function getBy(Callable $function)\n 2     {\n 3         if (!$this->count()) {\n 4             throw new \\UnderflowException('Collection is empty');\n 5         }\n 6         if ($function(reset($this->elements))) {\n 7             return reset($this->elements);\n 8         }\n 9         throw new \\OutOfBoundsException('Element not found');\n10     }\n

\n\n\n\n

De momento, vamos bien, pero ahora necesitamos estar seguros de que la función devuelve el objeto deseado y no el primero que haya. Tenemos que escribir un test mínimo que pruebe eso. Para ello, vuelvo a tirar de self-shunt, de modo que simplemente añado una propiedad que sólo está seteada en uno de los objetos, así como un método para comprobarla. De este modo es posible rastrearlo.

\n\n

Este es el código del test y la parte del self-shunt.

\n\n

 1     public function testGetByShouldSelectTheRightElement()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $target = clone $this;\n 5         $target->target = true;\n 6         $sut->append($this);\n 7         $sut->append($target);\n 8         $result = $sut->getBy(function (CollectionTest $element) {\n 9             return $element->isTarget();\n10         });\n11         $this->assertSame($target, $result);\n12     }\n13 \n14     public function isTarget()\n15     {\n16         return isset($this->target);\n17     }\n

\n\n\n\n

Para que el test pase, tengo que asegurarme de que examino todos los elementos de la lista:

\n\n

 1     public function getBy(Callable $function)\n 2     {\n 3         if (!$this->count()) {\n 4             throw new \\UnderflowException('Collection is empty');\n 5         }\n 6         foreach ($this->elements as $element) {\n 7             if ($function($element)) {\n 8                 return $element;\n 9             }\n10         }\n11         throw new \\OutOfBoundsException('Element not found');\n12     }\n

\n\n\n\n

¿Y sabes qué? Que el test pasa y hemos terminado de implementar getBy.

\n\n

Fin del capítulo

\n\n

Nuestra lista queda como sigue:

\n\n

Que pueda agregar la Collection (reduce)
Poder crear una Collection a partir de un array de objetos
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método isEmpty que nos diga si la colección está vacía
Método getType devuelve tipo de la colección

\n\n

Todavía nos quedan por desarrollar unos cuantos métodos interesantes, pero los dejaremos para el próximo capítulo.

\n\n\n

TDD en PHP. Un ejemplo con colecciones (5)

\n\n

Todavía nos quedan unas cuentas cosas pendientes en nuestra lista:

\n\n

Que pueda agregar la Collection (reduce)
Poder crear una Collection a partir de un array de objetos
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método isEmpty que nos diga si la colección está vacía
Método getType devuelve tipo de la colección

\n\n

Seleccionar cuál es la tarea que vamos a afrontar a continuación depende sobre todo de lo que deseemos o de lo que necesitemos. En un entorno de trabajo real esa decisión vendrá marcada por aquellas características a las que damos más valor y que ayudan a configurar un producto mínimo viable lo antes posible.

\n\n

Pero en nuestro ejercicio la selección de la próxima tarea se mueve por otros criterios, como puede ser que nos ayude a demostrar o ilustrar algún punto concreto de la metodología de TDD. Así, en esta serie hemos trabajado en lo siguiente:

\n\n

En cuanto a la metodología TDD:

\n\n

La importancia de escoger buenos tests mínimos que fallen
Qué código mínimo de producción escribir para que el test pase

\n\n

Es decir, cumplir las tres leyes de TDD de Robert C. Martin:

\n\n

No escribirás código de producción sin antes escribir un test que falle.
No escribirás más de un test unitario suficiente para fallar (y no compilar es fallar)
No escribirás más código del necesario para hacer pasar el test.

\n\n

Y, por otro lado, algunas técnicas prácticas, como:

\n\n

Descartar o posponer los tests que no fallan a la primera (violación de la primera ley de TDD).
Usar clases anónimas para disponer de test doubles de bajo coste y desechables.
Usar el self-shunt cuando necesitamos algún test double, lo que nos evita tener que tirar de mocks o inventarnos clases sin necesidad. Esto es: usar la propia clase TestCase como double.
Usar el código de producción como test para refactorizar el test: vamos modificando el test procurando que se mantenga en verde.
Identificar casos límite al descubrir que fallan tests anteriores, y que antes pasaban, en el último paso de implementación.

\n\n

Y también alguna técnica organizativa útil:

\n\n

Usar una lista de tareas para anotar en ella todas las ideas que se nos van ocurriendo, nuevos tests que deberíamos crear, etc, de modo que podamos mantener nuestra atención centrada en el test concreto en el que estamos trabajando.

\n\n

Reduciendo colecciones

\n\n

El primer elemento de la lista de tareas es implementar el método <code>reduce</code>. El concepto de reduce consiste en “resumir” la colección en un valor que agregue de algún modo sus elementos por medio de la función que le pasemos. Para ello, <code>reduce</code> tiene que poder arrastrar un acumulador que sea actualizado y devuelto por la función reductora. También podemos necesitar un valor para iniciar ese acumulador.

\n\n

<code>reduce</code> puede devolver cualquier cosa, desde un número a un array o incluso algún objeto. No hay limitaciones aquí. Lo más importante es que aquello que devuelva la función de reducción debe pasársele como parámetro, junto con el elemento actual.

\n\n

En fin, ¿cuál podría ser el test más sencillo que falle para este método? Pues siguiendo la línea de los artículos anteriores podemos empezar por el test de la colección vacía. Una colección vacía no acumularía nada ni podría reducirse a nada, así que parece bastante razonable esperar que nos devuelva <code>null</code>. Lo malo es que ese test va a pasar a la primera puesto que cualquier método que no devuelva nada explícitamente devolverá null.

\n\n

Por lo tanto, este test no nos vale. ¿Qué podríamos hacer entonces? Resulta que hemos mencionado que podríamos pasar un valor inicial del acumulador, por lo que en el caso de la lista vacía podríamos devolver ese mismo valor ya que al no tener elementos que iterar no se podría aplicar la función de reducción.

\n\n

1     public function testReduceSouldReturnInitialValueForEmptyCollection()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n5            return $accumulator + 1;\n6         }, 0);\n7         $this->assertEquals(0, $result);\n8     }\n

\n\n\n\n

El test fallará por razones obvias y nos pide crear el método <code>reduce</code>, cosa que ya podemos hacer con la implementación obvia devolviendo <code>0</code>, es decir, el mínimo código para que el test pase.

\n\n

1     public function reduce(Callable $function, $initial)\n2     {\n3         return 0;\n4     }\n

\n\n\n\n

Bien, ¿y por qué no devolver directamente el valor que pasamos en $initial?

\n\n

Después de un tiempo practicando TDD puedes pensar que este baby step es demasiado baby y que puedes lidiar con confianza con algunos pasos más grandes. Y no te equivocarías. Como he mencionado en algún momento de la serie, estos pasos se van adaptando a las circunstancias y los puedes ampliar o reducir dependiendo, precisamente, de tu confianza en lo que estás haciendo.

\n\n

Pero yo ahora prefiero hacer que los tests me vayan marcando el camino. Así, en lugar de dar un paso grande, voy a dar uno más pequeño, que además me servirá para probar que <code>$initial</code> puede ser cualquier tipo de valor. Crearé otro test.

\n\n

1     public function testReduceShouldAcceptAnyTypeForInitialValue()\n2     {\n3         $sut = $this->getCollection();\n4         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n5             return $accumulator + 1;\n6         }, \"\");\n7         $this->assertEquals(\"\", $result);\n8     }\n

\n\n\n\n

Este test falla y, al fallar, me fuerza a una nueva implementación no tan obvia y más general.

\n\n

Si usase la implementación obvia mínima para pasar este nuevo test, que sería devolver la cadena vacía, el test anterior dejaría de pasar. Eso indica que tengo que implementar algo que pueda satisfacer ambos tests a la vez. Y eso, niñas y niños, es la razón por la que deberíamos dar pasos cortos para forzar que los tests nos digan lo que debemos hacer.

\n\n

En este caso, la implementación más sencilla para eso es devolver el propio parámetro.

\n\n

1     public function reduce(Callable $function, $initial)\n2     {\n3         return $initial;\n4     }\n

\n\n\n\n

Hemos dicho que <code>reduce</code> puede devolver cualquier cosa, pero pasando un valor inicial es bastante lógico suponer que el tipo devuelto por reduce es el mismo que el del valor inicial que se pasa. Debería ser obvio que probar esto, en este momento, es inútil puesto que al devolver lo mismo que recibimos el test no nos va a aportar nada. Por tanto, deberíamos buscar otra cosa para probar.

\n\n

Por ejemplo, podríamos probar que la función de reducción se aplica para una colección de un elemento.

\n\n

Nuestra función de reducción de prueba es muy sencilla y se limita a incrementar el acumulador que se le pasa como segundo parámetro, así que nuestro nuevo test podría ser este:

\n\n

1    public function testReduceShouldApplyCallableToOneElement()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n6             return $accumulator + 1;\n7         }, 0);\n8         $this->assertEquals(1, $result);\n9     }\n

\n\n\n\n

Como el test falla, implementemos algo para que pase:

\n\n

1     public function reduce(Callable $function, $initial)\n2     {\n3         return $function(reset($this->elements), $initial);\n4     }\n

\n\n\n\n

Y, aunque el nuevo test pasa, se nos rompen los dos test anteriores. Nuestra implementación tiene que lidiar con un caso límite que, ¡sorpresa! es el de la colección vacía.

\n\n

1     public function reduce(Callable $function, $initial)\n2     {\n3         if (!$this->count()) {\n4             return $initial;\n5         }\n6         return $function(reset($this->elements), $initial);\n7     }\n

\n\n\n\n

Y con esta implementación volvemos a verde.

\n\n

He mencionado varias veces que la colección vacía es un caso límite, pero no he explicado cómo podemos decir esto. Aprovecho ahora:

\n\n

La colección vacía es un caso límite porque no puede ser tratado por el algoritmo general. Es una situación especial que no cumple los supuestos que asumimos respecto a las situaciones cubiertas por el algoritmo. Normalmente podemos detectar estos casos con TDD cuando falla un test anterior a la implementación de una solución general.

\n\n

Podemos prever algunos casos límite si conocemos el dominio. Por ejemplo, en el caso de las colecciones, tenemos tres casos claros:

\n\n

La colección no tiene ningún elemento.
La colección tiene un elemento.
La colección tiene más de un elemento.

\n\n

Por esa razón intentamos crear tests que cubran las tres situaciones. Al hacerlo podemos descubrir varias cosas:

\n\n

Al implementar una solución más general para pasar el test de un caso, se rompen tests previos: eso indicaría que los tests rotos se aplican sobre un caso especial.
Al implementar una solución más general para pasar el test de un caso, no se rompen tests previos: indicaría que los casos tratados por esos tests no son especiales.
Al crear un nuevo test para probar otro caso, el test falla: indicaría que no hemos implementado una solución lo bastante general.
Al crear un nuevo test para probar otro caso, el test pasa a la primera: indicaría que ya hemos implementado una solución general.

\n\n

En principio nos quedaría probar con una colección de más elementos. El resultado de este test es previsible: tenemos un fallo porque la solución no es lo bastante general.

\n\n

 1     public function testReduceShouldApplyFunctionToSeveralElements()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $sut->append($this);\n 6         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n 7             return $accumulator + 1;\n 8         }, 0);\n 9         $this->assertEquals(2, $result);\n10     }\n

\n\n\n\n

La razón es que no estamos iterando:

\n\n

 1     public function reduce(Callable $function, $initial)\n 2     {\n 3         if (!$this->count()) {\n 4             return $initial;\n 5         }\n 6         foreach ($this->elements as $element) {\n 7             $initial = $function($element, $initial);\n 8         }\n 9         return $initial;\n10     }\n

\n\n\n\n

Y con esto resulta que hemos conseguido implementar <code>reduce</code>. Algo que podemos tachar de la lista de tareas.

\n\n

Poder crear una Collection a partir de un array de objetos
Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método isEmpty que nos diga si la colección está vacía
Método getType devuelve tipo de la colección

\n\n

Métodos útiles para nuestras colecciones

\n\n

En nuestra lista nos quedan varios métodos que pueden ser de utilidad para crear nuestras colecciones.

\n\n

El primero de ellos tiene que ver con la posibilidad de crear una colección a partir de un array, se supone que de objetos.

\n\n

En este caso, parece buena idea usar un named constructor, que instancie una nueva colección a partir de un array que contenga al menos un objeto. Si el array estuviese vacío no podríamos instanciar <code>Collection</code> porque no sabríamos el tipo de objetos que contiene, salvo que se lo indicásemos explícitamente, que es lo que hacemos con <code>Collection::of</code>.

\n\n

Por otra parte, pueden existir arrays no válidos, aparte del vacío, como aquellos que no contengan objetos o que lleven mezclados objetos de distinto tipo, con elementos que no sean objetos.

\n\n

Así que tenemos que poner algunas reglas para definir el comportamiento de este método, que será lo que testeemos:

\n\n

Si el array está vacío, lanzar una excepción.
Si el primer elemento del array no es un objeto válido lanzar una excepción.
Si el array tiene al menos un elemento que es un objeto, crear la colección, tomando como tipo el del primer objeto presente en el array.
Una vez determinado el tipo de la colección, añadimos todos los objetos de ese tipo.
Si encontramos algún objeto de otro tipo lanzamos una excepción.

\n\n

Así que ahora tenemos una lista específica de tareas para desarrollar este método.

\n\n

¿Cuál sería el mejor punto para empezar? Podríamos hacerlo siguiendo la lista de tareas. Otro enfoque sería comenzar por la situación válida más sencilla (la tercera de nuestra lista) y añadir posteriormente las demás. La verdad es que, como veremos, va a dar un poco igual.

\n\n

Particularmente no me gusta comenzar por un caso que lanza una excepción, se llaman así por ser excepcionales, así que me voy directamente al primer caso de uso normal y decido que este será el test mínimo:

\n\n

1     public function testCollectShouldReturnInstanceOfCollection()\n2     {\n3         $sut = Collection::collect([]);\n4         $this->assertAttributeEquals(\\stdClass::class, 'type', $sut);\n5     }\n

\n\n\n\n

El test falla porque no existe el método collect. Lo creamos y observamos que vuelve a fallar porque no devolvemos nada y es, por tanto, momento de implementar alguna solución.

\n\n

La implementación más sencilla podría ser esta:

\n\n

1     public static function collect(array $array)\n2     {\n3         return Collection::of(\\stdClass::class);\n4     }\n

\n\n\n\n

Que nos sirve para pasar el test.

\n\n

Ahora quiero probar que el método toma en cuenta el array que le pasamos para instanciar la clase. Para eso hago un test que falle.

\n\n

1     public function testCollectShouldUseFirstElementToDecideCollectionType()\n2     {\n3         $sut = Collection::collect([new \\stdClass()]);\n4         $this->assertAttributeEquals(\\stdClass::class, 'type', $sut);\n5     }\n

\n\n\n\n

Y como falla, me obliga a implementar. Si ahora forzase a crear una <code>Collection</code> con <code>CollectionTest::class</code> el test anterior fallaría, por lo que debo implementar una solución más general.

\n\n

1     public static function collect(array $elements)\n2     {\n3         $type = get_class($elements[0]);\n4         return Collection::of($type);\n5     }\n

\n\n\n\n

Este test pasa, pero falla el anterior. Como hemos visto antes, un test anterior que falla suele implicar un caso límite que aparece al intentar generalizar un algoritmo. Pero es que este caso coincide con uno de los casos que queríamos controlar en particular, el array vacío que iba a generar una excepción.

\n\n

Necesitamos un test que compruebe específicamente este caso. Con esto me doy cuenta de que he comenzado por un test que no sirve, lo que me muestra que siguiendo la metodología TDD los tests parecen cuidarse a sí mismos. Es decir: incluso no teniendo las cosas muy claras al principio, TDD nos va llevando hacia un camino productivo.

\n\n

En resumidas cuentas, eliminamos el test malo y preparamos un test adecuado a lo que queremos probar ahora:

\n\n

1     public function testShouldFailWithExceptionCollectingEmptyArray()\n2     {\n3         $this->expectException(\\InvalidArgumentException::class);\n4         Collection::collect([]);\n5     }\n

\n\n\n\n

Hay que implementar para volver a verde:

\n\n

1     public static function collect(array $elements)\n2     {\n3         if (!count($elements)) {\n4             throw new \\InvalidArgumentException('Can\\'t collect an empty array');\n5         }\n6         $type = get_class($elements[0]);\n7         return Collection::of($type);\n8     }\n

\n\n\n\n

Ahora tenemos que probar que <code>collect</code> es capaz de llenar la colección con los objetos que se encuentran en el array. El test mínimo que lo demuestra podría ser este:

\n\n

1     public function testShouldPopulateCollectionWithUniqueElementInArray()\n2     {\n3         $sut = Collection::collect([\n4             $this\n5         ]);\n6         $this->assertEquals(1, $sut->count());\n7     }\n

\n\n\n\n

Y una implementación mínima sería la siguiente:

\n\n

 1     public static function collect(array $elements)\n 2     {\n 3         if (!count($elements)) {\n 4             throw new \\InvalidArgumentException('Can\\'t collect an empty array');\n 5         }\n 6         $type = get_class($elements[0]);\n 7         $collection = Collection::of($type);\n 8         $collection->append(reset($elements));\n 9         return $collection;\n10     }\n

\n\n\n\n

Para forzarnos a implementar el método general necesitamos un nuevo test, que pruebe que un array de varios elementos genera una colección con esos elementos.

\n\n

1     public function testShouldPopulateCollectionWithSeveralElementsInArray()\n2     {\n3         $sut = Collection::collect([\n4             $this,\n5             $this\n6         ]);\n7         $this->assertEquals(2, $sut->count());\n8     }\n

\n\n\n\n

Para pasar el test, ya podríamos implementar el método general:

\n\n

 1     public static function collect(array $elements)\n 2     {\n 3         if (!count($elements)) {\n 4             throw new \\InvalidArgumentException('Can\\'t collect an empty array');\n 5         }\n 6         $type = get_class($elements[0]);\n 7         $collection = Collection::of($type);\n 8         foreach ($elements as $element) {\n 9             $collection->append($element);\n10         }\n11         return $collection;\n12     }\n

\n\n\n\n

La siguiente tarea que tenemos es lanzar una excepción si algún elemento del array no es del tipo adecuado para la colección. Podríamos hacer un test para probarlo, pero este test va a pasar a la primera.

\n\n

1     public function testShouldFailWithExceptionIfWrongTypeElementFound()\n2     {\n3         $this->expectException(\\UnexpectedValueException::class);\n4         Collection::collect([\n5             $this,\n6             new \\stdClass()\n7         ]);\n8     }\n

\n\n\n\n

Esto era de esperar porque ya estaba contemplado en el método <code>append</code>, al que recurrimos para añadir los elementos del array a la colección en vez de incluirlos a mano en el almacén interno. Este patrón se llama self-encapsulation y consiste precisamente en que una clase utiliza internamente métodos para alterar sus propiedades, en vez de manejarlas directamente, de tal manera que estos métodos pueden encapsular guardas, saneamientos y otras operaciones.

\n\n

Ahora podemos considerar que hemos terminado de implementar el método <code>collect</code>. Es momento de refactorizarlo.

\n\n

Los tests nos protegen contra problemas derivados de los cambios que hagamos. Al refactorizar sólo estamos cambiando la implementación, no la interfaz ni el comportamiento público, y eso es lo que nos aseguran los tests en este momento.

\n\n

 1     public static function collect(array $elements)\n 2     {\n 3         if (!count($elements)) {\n 4             throw new \\InvalidArgumentException('Can\\'t collect an empty array');\n 5         }\n 6         $collection = Collection::of(get_class($elements[0]));\n 7         return array_map(function ($element) use ($collection) {\n 8             $collection->append($element);\n 9         }, $elements);\n10     }\n

\n\n\n\n

Aquí está nuestra lista de tareas actualizada.

\n\n

Método toArray y/o mapToArray que devuelva los elementos de Collection como un array
Método isEmpty que nos diga si la colección está vacía
Método getType devuelve tipo de la colección

\n\n

Devolviendo el contenido de la colección

\n\n

Usar colecciones puede ser muy útil y elegante, pero si interactuamos con código de terceros es muy posible que necesitemos disponer del contenido de la colección en un array. Lo cierto es que lo estamos almacenando internamente en un array por lo que, simplemente, podríamos devolverlo y punto.

\n\n

Pero, como siempre, deberíamos probar eso con un test.

\n\n

1     public function testShouldMapEmptyCollectionToEmptyArray()\n2     {\n3         $sut = $this->getCollection();\n4         $this->assertEquals([], $sut->toArray());\n5     }a\n

\n\n\n\n

Como suele pasar con estos tests iniciales, no existe el método y nos pide una implementación mínima, que es bastante obvia.

\n\n

1     public function toArray()\n2     {\n3         return [];\n4     }\n

\n\n\n\n

Para que sea útil, el método debe trabajar con Collections que tengan algún elemento.

\n\n

1     public function testShouldReturnArrayFromCollection()\n2     {\n3         $sample = [$this];\n4         $sut = Collection::collect($sample);\n5         $this->assertEquals($sample, $sut->toArray());\n6     }\n

\n\n\n\n

La siguiente implementación obvia romperá nuestro test anterior sobre la colección vacía:

\n\n

1     public function toArray()\n2     {\n3         return $this->elements;\n4     }\n

\n\n\n\n

Así que hay que contemplar el caso límite, cosa que no nos debería sorprender:

\n\n

1     public function toArray() : array\n2     {\n3         if (!$this->elements) {\n4             return [];\n5         }\n6         return $this->elements;\n7     }\n

\n\n\n\n

No merece la pena probar nuevos tamaños de colección, cualquier test que se nos ocurra al respecto pasará y, por tanto, no aportará ninguna información que nos fuerce a realizar cambios en la implementación.

\n\n

Pero lo cierto es que también planteamos un método mapToArray. La idea es la siguiente:

\n\n

En algunas ocasiones nos interesa convertir nuestros objetos a una estructura de array asociativo (diversos mecanismos de persistencia nos piden esto). Por desgracia nuestra definición de Collection impide que podamos mapear los objetos como array para generar una “colección de arrays”, aunque existe un atajo:

\n\n

1 \t$collectionArray = $collection->reduce(function(Persistible $element, $accumulator)\\\n2  {\n3 \t\t$accumulator[] = $element->toArray();\n4 \t}, array());\n

\n\n\n\n

Esta solución funciona, pero sería interesante encapsularla, de modo que fuese más fácil de usar. Una posibilidad es crear un método mapToArray, pero ¿por qué no encapsularla en toArray pasando la función de conversión a array como un parámetro opcional? Al fin y al cabo, generar un array a partir de la colección es el caso más simple de mapeo.

\n\n

Por supuesto, debemos probar esto con un test.

\n\n

El caso de la colección vacía ya lo hemos probado con el test anterior, por lo que podemos pasar al siguiente test mínimo:

\n\n

1     public function testShouldBeAbleToMapCollectionToArray()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $this->assertEquals(['mapped'], $sut->toArray(function(CollectionTest $eleme\\\n6 nt) {\n7             return 'mapped';\n8         }));\n9     }\n

\n\n\n\n

Como no hemos implementado ningún mapeo, el test no pasa.

\n\n

La forma de hacerlo pasar es sencilla:

\n\n

1     public function toArray() : array\n2     {\n3         if (!$this->elements) {\n4             return [];\n5         }\n6         return ['mapped'];\n7     }\n

\n\n\n\n

Con esto, el test pasa, pero rompemos un test anterior, el de la definición actual del método toArray. Es buena cosa, porque nos obliga a implementar algo diferente.

\n\n

Por ejemplo, esto:

\n\n

 1     public function toArray(Callable $function = null) : array\n 2     {\n 3         if (!$this->elements) {\n 4             return [];\n 5         }\n 6         if (!$function) {\n 7             return $this->elements;\n 8         }\n 9         return ['mapped'];\n10     }\n

\n\n\n\n

Nos queda menos. El siguiente test probará que podemos mapear dos elementos en el array, pero aquí voy a hacer algo que puede parecer un churro pero que me va a servir para hacer una explicación que hasta ahora he pasado por alto sobre la naturaleza de los baby-steps.

\n\n

Pero primero, el test:

\n\n

 1     public function testShouldBeAbleToMapCollectionWithTwoElementsToArray()\n 2     {\n 3         $sut = $this->getCollection();\n 4         $sut->append($this);\n 5         $sut->append($this);\n 6         $this->assertEquals(['mapped', 'mapped'], $sut->toArray(function(CollectionT\\\n 7 est $element) {\n 8             return 'mapped';\n 9         }));\n10     }\n

\n\n\n\n

Falla. Implementemos una solución:

\n\n

 1     public function toArray(Callable $function = null) : array\n 2     {\n 3         if (!$this->elements) {\n 4             return [];\n 5         }\n 6         if (!$function) {\n 7             return $this->elements;\n 8         }\n 9         return [\n10             'mapped',\n11             'mapped'\n12         ];\n13     }\n

\n\n\n\n

¿Cómo te quedas?

\n\n

Nuestro último test pasa, nuestro test anterior se rompe. Este baby-step parece ridículo, pero no lo es, de ningún modo. Vamos a ver lo que nos aporta:

\n\n

En primer lugar, nos ha permitido tener un test que pasa y que es válido, facilitándonos cambiar una implementación para cubrir un nuevo caso.
Pero al fallar un test anterior, nos dice que debemos buscar una implementación que pueda dar cuenta de los dos tests. Es decir, un algoritmo más general.
En tercer lugar, la propia solución apunta que debemos iterar elementos para lograr el resultado deseado.

\n\n

Así que vamos a implementar de otra manera, en este caso, dando un paso un poco más largo:

\n\n

 1     public function toArray(Callable $function = null) : array\n 2     {\n 3         if (!$this->elements) {\n 4             return [];\n 5         }\n 6         if (!$function) {\n 7             return $this->elements;\n 8         }\n 9         $map = [];\n10         foreach ($this->elements as $element) {\n11             $map[] = $function($element);\n12         }\n13         return $map;\n14     }\n

\n\n\n\n

Esta implementación ya es lo bastante general como para que no necesitemos más tests. Posiblemente podamos refactorizar nuestra solución y hacerla más concisa:

\n\n

 1     public function toArray(Callable $function = null) : array\n 2     {\n 3         if (!$this->elements) {\n 4             return [];\n 5         }\n 6         if (!$function) {\n 7             return $this->elements;\n 8         }\n 9         return array_map($function, $this->elements);\n10     }\n

\n\n\n\n

La lista se reduce y ya estamos acabando:

\n\n

Método isEmpty que nos diga si la colección está vacía
Método getType devuelve tipo de la colección

\n\n

Métodos de utilidad

\n\n

Tenemos un par de métodos de utilidad para nuestra Collection y que no hubiera estado de más implementar antes. Lo bueno es que serán fáciles de implementar y nos servirán para aprender un par de cosas más:

\n\n

1     public function testShouldGetTheTypeOfCollection()\n2     {\n3         $sut = Collection::of(CollectionTest::class);\n4         $this->assertEquals(CollectionTest::class, $sut->getType());\n5     }\n

\n\n\n\n

Testear un método que va a dar un resultado obvio como un getter no tiene mucho sentido, a no ser que exista una expectativa razonable de que no va a ser un getter “tonto” y que, con el tiempo, podría recibir algún tipo de implementación. En ese caso, el test nos serviría para cubrir una posible regresión.

\n\n

Pero en muchos casos estos test simplemente no se hacen hasta que son necesarios. Los únicos beneficios que se me ocurre que podría ofrecer el test de un getter “tonto” serían:

\n\n

Forzarnos a hacer la implementación
Contribuir al índice de cobertura de código

\n\n

La implementación es obvia:

\n\n

1     public function getType()\n2     {\n3         return $this->type;\n4     }\n

\n\n\n\n

Por último, isEmpty tiene un poco más de comportamiento. Es un método de utilidad para encapsular una información que podemos obtener de otra manera, aunque un poco más alambicada:

\n\n

1 \tif ($collection->count() === 0) { // Collection is empty }\n

\n\n\n\n

Hagamos un test que falle:

\n\n

1     public function testShouldTellIfCollectionIsEmpty()\n2     {\n3         $sut = $this->getCollection();\n4         $this->assertTrue($sut->isEmpty());\n5     }\n

\n\n\n\n

Obviamente nos pide implementar y devolver true:

\n\n

1     public function isEmpty() : bool\n2     {\n3         return true;\n4     }\n

\n\n\n\n

Pero si la colección tiene elementos, debería devolver false.

\n\n

1     public function testShouldTellIfCollectionIsNotEmpty()\n2     {\n3         $sut = $this->getCollection();\n4         $sut->append($this);\n5         $this->assertFalse($sut->isEmpty());\n6     }\n

\n\n\n\n

Y la implementación necesaria es sencilla:

\n\n

1     public function isEmpty() : bool\n2     {\n3         return !$this->elements;\n4     }\n

\n\n\n\n

Y, con esto, terminamos.

\n\n

Refactor final

\n\n

Hemos desarrollado nuestra clase Collection y tachado todos los elementos de la lista. Seguramente queda mucho campo para mejorar esta clase y, tal vez, implementar más métodos. Por el momento, la dejamos así.

\n\n

Puede ser buen momento para refactorizar el código, que está completamente protegido por los tests. De este modo, podemos encontrar implementaciones mejores o más elegantes que, en un futuro, nos permitan intervenir sobre el código, bien para corregir problemas, bien para añadir nuevas funcionalidades o modificar comportamientos de la clase.

\n\n

Por mi parte, voy a revisar cuestiones como los return type de los métodos y refactorizar algunas cosas con auto-encapsulación y, si fuese posible, eliminar algunos bucles También puede ser el momento de reordenar los métodos para agruparlos por afinidad. Este ha sido el resultado:

\n\n

  1 <?php\n  2 \n  3 namespace Fi\\Collections;\n  4 \n  5 class Collection\n  6 {\n  7     /**\n  8      * @var array\n  9      */\n 10     private $elements;\n 11     /**\n 12      * @var string\n 13      */\n 14     private $type;\n 15 \n 16     private function __construct(string $type)\n 17     {\n 18         $this->type = $type;\n 19     }\n 20 \n 21     public static function of(string $type) : Collection\n 22     {\n 23         return new self($type);\n 24     }\n 25 \n 26     public static function collect(array $elements)\n 27     {\n 28         if (!count($elements)) {\n 29             throw new \\InvalidArgumentException('Can\\'t collect an empty array');\n 30         }\n 31 \n 32         $collection = Collection::of(get_class($elements[0]));\n 33 \n 34         array_map(function ($element) use ($collection) {\n 35             $collection->append($element);\n 36         }, $elements);\n 37 \n 38         return $collection;\n 39     }\n 40 \n 41     public function count()\n 42     {\n 43         return count($this->elements);\n 44     }\n 45 \n 46     public function append($element) : void\n 47     {\n 48         $this->guardAgainstInvalidType($element);\n 49         $this->elements[] = $element;\n 50     }\n 51 \n 52     protected function guardAgainstInvalidType($element) : void\n 53     {\n 54         if (!$this->isSupportedType($element)) {\n 55             throw new \\UnexpectedValueException('Invalid Type');\n 56         }\n 57     }\n 58 \n 59     public function each(Callable $function) : Collection\n 60     {\n 61         if ($this->isEmpty()) {\n 62             return $this;\n 63         }\n 64 \n 65         array_map($function, $this->elements);\n 66 \n 67         return $this;\n 68     }\n 69 \n 70     public function map(Callable $function) : Collection\n 71     {\n 72         if ($this->isEmpty()) {\n 73             return clone $this;\n 74         }\n 75 \n 76         $first = $function(reset($this->elements));\n 77         $mapped = Collection::of(get_class($first));\n 78         $mapped->append($first);\n 79 \n 80         while ($object = next($this->elements)) {\n 81             $mapped->append($function($object));\n 82         }\n 83 \n 84         return $mapped;\n 85     }\n 86 \n 87     public function filter(Callable $function) : Collection\n 88     {\n 89         $filtered = Collection::of($this->getType());\n 90 \n 91         if ($this->isEmpty()) {\n 92             return $filtered;\n 93         }\n 94 \n 95         foreach ($this->elements as $element) {\n 96             if ($function($element)) {\n 97                 $filtered->append($element);\n 98             }\n 99         }\n100 \n101         return $filtered;\n102     }\n103 \n104     public function getBy(Callable $function)\n105     {\n106         if ($this->isEmpty()) {\n107             throw new \\UnderflowException('Collection is empty');\n108         }\n109         foreach ($this->elements as $element) {\n110             if ($function($element)) {\n111                 return $element;\n112             }\n113         }\n114         throw new \\OutOfBoundsException('Element not found');\n115     }\n116 \n117     public function reduce(Callable $function, $initial)\n118     {\n119         if ($this->isEmpty()) {\n120             return $initial;\n121         }\n122 \n123         foreach ($this->elements as $element) {\n124             $initial = $function($element, $initial);\n125         }\n126 \n127         return $initial;\n128     }\n129 \n130     public function toArray(Callable $function = null) : array\n131     {\n132         if ($this->isEmpty()) {\n133             return [];\n134         }\n135         if (!$function) {\n136             return $this->elements;\n137         }\n138 \n139         return array_map($function, $this->elements);\n140     }\n141 \n142     public function getType() : string\n143     {\n144         return $this->type;\n145     }\n146 \n147     public function isEmpty() : bool\n148     {\n149         return !$this->count();\n150     }\n151 \n152     protected function isSupportedType($element) : bool\n153     {\n154         return is_a($element, $this->getType());\n155     }\n156 }\n

\n\n\n\n

También podríamos refactorizar el test. Ahora que hemos creado algunos métodos de utilidad como isEmpty o getType, podemos cambiar algunos tests para emplearlos, de modo que sean más sencillos y más explícitos. También nos permiten eliminar las aserciones sobre propiedades privadas, que aunque se pueden hacer no deberían hacerse si es posible evitarlo.

\n\n

A mí me ha quedado así:

\n\n

  1 <?php\n  2 \n  3 namespace Test\\Collections;\n  4 \n  5 use Fi\\Collections\\Collection;\n  6 use PHPUnit\\Framework\\TestCase;\n  7 \n  8 class CollectionTest extends TestCase\n  9 {\n 10     public function testShouldInitialize()\n 11     {\n 12         $this->assertInstanceOf(Collection::class, $this->getCollection());\n 13     }\n 14 \n 15     private function getCollection() : Collection\n 16     {\n 17         return Collection::of(get_class($this));\n 18     }\n 19 \n 20     public function testShouldBeConstructedEmpty()\n 21     {\n 22         $sut = $this->getCollection();\n 23         $this->assertEquals(0, $sut->count());\n 24     }\n 25 \n 26     public function testShouldBeAbleToAppendOneElement()\n 27     {\n 28         $sut = $this->getCollection();\n 29         $sut->append($this);\n 30         $this->assertEquals(1, $sut->count());\n 31     }\n 32 \n 33     public function testShouldBeAbleToAppendTwoElements()\n 34     {\n 35         $sut = $this->getCollection();\n 36         $sut->append($this);\n 37         $sut->append($this);\n 38         $this->assertEquals(2, $sut->count());\n 39     }\n 40 \n 41     public function testShouldInitializeWithAType()\n 42     {\n 43         $sut = Collection::of(CollectionTest::class);\n 44         $this->assertInstanceOf(Collection::class, $sut);\n 45     }\n 46 \n 47     public function testShouldNotStoreObjectOfIncorrectType()\n 48     {\n 49         $sut = $this->getCollection();\n 50         $this->expectException(\\UnexpectedValueException::class);\n 51         $sut->append(new class\n 52         {\n 53         });\n 54     }\n 55 \n 56     public function testShouldBeAbleToStoreSubClasses()\n 57     {\n 58         $sut = $this->getCollection();\n 59         $sut->append(new class extends CollectionTest\n 60         {\n 61         });\n 62         $this->assertEquals(1, $sut->count());\n 63     }\n 64 \n 65     public function testEachShouldNotActOnEmptyCollection()\n 66     {\n 67         $sut = $this->getCollection();\n 68         $log = '';\n 69         $sut->each(function () use (&$log) {\n 70             $log .= '*';\n 71         });\n 72         $this->assertEquals('', $log);\n 73     }\n 74 \n 75     public function testEachShouldIterateOverOneElement()\n 76     {\n 77         $sut = $this->getCollection();\n 78         $sut->append($this);\n 79         $log = '';\n 80         $sut->each(function () use (&$log) {\n 81             $log .= '*';\n 82         });\n 83         $this->assertEquals('*', $log);\n 84     }\n 85 \n 86     public function testEachShouldIterateOverSeveralElements()\n 87     {\n 88         $sut = $this->getCollection();\n 89         $sut->append($this);\n 90         $sut->append($this);\n 91         $log = '';\n 92         $sut->each(function () use (&$log) {\n 93             $log .= '*';\n 94         });\n 95         $this->assertEquals('**', $log);\n 96     }\n 97 \n 98     public function testEachShouldPassEveryElementToCallable()\n 99     {\n100         $sut = $this->getCollection();\n101         $sut->append($this);\n102         $sut->append($this);\n103         $log = '';\n104         $sut->each(function (CollectionTest $element) use (&$log) {\n105             $log .= '*';\n106         });\n107         $this->assertEquals('**', $log);\n108     }\n109 \n110     public function testEachShouldAllowPipelining()\n111     {\n112         $sut = $this->getCollection();\n113         $sut->append($this);\n114         $log = '';\n115         $result = $sut->each(function (CollectionTest $element) use (&$log) {\n116             $log .= '*';\n117         });\n118         $this->assertInstanceOf(Collection::class, $result);\n119     }\n120 \n121     public function testEachShouldAllowPipeliningOnEmptyCollection()\n122     {\n123         $sut = $this->getCollection();\n124         $log = '';\n125         $result = $sut->each(function (CollectionTest $element) use (&$log) {\n126             $log .= '*';\n127         });\n128         $this->assertInstanceOf(Collection::class, $result);\n129     }\n130 \n131     public function testMapShouldAllowPipeliningOnEmptyCollection()\n132     {\n133         $sut = $this->getCollection();\n134         $result = $sut->map(function (CollectionTest $element) {\n135             return $element;\n136         });\n137         $this->assertInstanceOf(Collection::class, $result);\n138     }\n139 \n140     public function testMapShouldReturnEmptyCollectionWhenEmptyCollection()\n141     {\n142         $sut = $this->getCollection();\n143         $result = $sut->map(function (CollectionTest $element) {\n144             return $element;\n145         });\n146         $this->assertInstanceOf(Collection::class, $result);\n147         $this->assertEquals(0, $result->count());\n148     }\n149 \n150     public function testMapShoulReturnAnotherCollection()\n151     {\n152         $sut = $this->getCollection();\n153         $result = $sut->map(function (CollectionTest $element) {\n154             return $element;\n155         });\n156         $this->assertNotSame($sut, $result);\n157     }\n158 \n159     public function testMapShouldMapOneElement()\n160     {\n161         $sut = $this->getCollection();\n162         $sut->append($this);\n163         $result = $sut->map(function (CollectionTest $element) {\n164             return new MappedObject();\n165         });\n166         $this->assertEquals(MappedObject::class, $result->getType());\n167         $this->assertEquals(1, $result->count());\n168     }\n169 \n170     public function testMapShouldMapSeveralElements()\n171     {\n172         $sut = $this->getCollection();\n173         $sut->append($this);\n174         $sut->append($this);\n175         $result = $sut->map(function (CollectionTest $element) {\n176             return new MappedObject();\n177         });\n178         $this->assertEquals(MappedObject::class, $result->getType());\n179         $this->assertEquals(2, $result->count());\n180     }\n181 \n182     public function testFilterShouldReturnCollection()\n183     {\n184         $sut = $this->getCollection();\n185         $result = $sut->filter(function (CollectionTest $element) {\n186             return false;\n187         });\n188         $this->assertInstanceOf(Collection::class, $result);\n189     }\n190 \n191     public function testFilterShouldReturnAnotherCollection()\n192     {\n193         $sut = $this->getCollection();\n194         $result = $sut->filter(function (CollectionTest $element) {\n195             return false;\n196         });\n197         $this->assertNotSame($sut, $result);\n198     }\n199 \n200     public function testFilterShouldReturnAnotherCollectionWithTheSameType()\n201     {\n202         $sut = $this->getCollection();\n203         $result = $sut->filter(function (CollectionTest $element) {\n204             return false;\n205         });\n206         $this->assertEquals(CollectionTest::class, $result->getType());\n207     }\n208 \n209     public function testFilterShouldIncludeElementWhenCallableReturnTrue()\n210     {\n211         $sut = $this->getCollection();\n212         $sut->append($this);\n213         $result = $sut->filter(function (CollectionTest $element) {\n214             return true;\n215         });\n216         $this->assertEquals(1, $result->count());\n217     }\n218 \n219     public function testFilterShouldNotIncludeElementWhenCallableReturnFalse()\n220     {\n221         $sut = $this->getCollection();\n222         $sut->append($this);\n223         $result = $sut->filter(function (CollectionTest $element) {\n224             return false;\n225         });\n226         $this->assertEquals(0, $result->count());\n227     }\n228 \n229     public function testFilterShouldIterateOverAllElements()\n230     {\n231         $sut = $this->getCollection();\n232         $sut->append($this);\n233         $sut->append(clone $this);\n234         $result = $sut->filter(function (CollectionTest $element) {\n235             return true;\n236         });\n237         $this->assertEquals($sut, $result);\n238     }\n239 \n240     public function testGetByShouldFailWithExceptionWhenEmptyCollection()\n241     {\n242         $sut = $this->getCollection();\n243         $this->expectException(\\UnderflowException::class);\n244         $sut->getBy(function (CollectionTest $element) {\n245             return true;\n246         });\n247     }\n248 \n249     public function testGetByShouldFailWithExceptionWhenElementNotFound()\n250     {\n251         $sut = $this->getCollection();\n252         $sut->append($this);\n253         $this->expectException(\\OutOfBoundsException::class);\n254         $sut->getBy(function (CollectionTest $element) {\n255             return false;\n256         });\n257     }\n258 \n259     public function testGetByShouldReturnFoundElement()\n260     {\n261         $sut = $this->getCollection();\n262         $sut->append($this);\n263         $result = $sut->getBy(function (CollectionTest $element) {\n264             return true;\n265         });\n266         $this->assertSame($this, $result);\n267     }\n268 \n269     public function testGetByShouldReturnTheRightElement()\n270     {\n271         $sut = $this->getCollection();\n272         $target = clone $this;\n273         $target->target = true;\n274         $sut->append($this);\n275         $sut->append($target);\n276         $result = $sut->getBy(function (CollectionTest $element) {\n277             return $element->isTarget();\n278         });\n279         $this->assertSame($target, $result);\n280     }\n281 \n282     public function testReduceShouldReturnInitialValueWhenCollectionIsEmpty()\n283     {\n284         $sut = $this->getCollection();\n285         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n286            return $accumulator + 1;\n287         }, 0);\n288         $this->assertEquals(0, $result);\n289     }\n290 \n291     public function testReduceInitialValueShouldAcceptAnyType()\n292     {\n293         $sut = $this->getCollection();\n294         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n295             return $accumulator + 1;\n296         }, \"\");\n297         $this->assertEquals(\"\", $result);\n298     }\n299 \n300     public function testReduceShouldApplyCallableToOneElement()\n301     {\n302         $sut = $this->getCollection();\n303         $sut->append($this);\n304         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n305             return $accumulator + 1;\n306         }, 0);\n307         $this->assertEquals(1, $result);\n308     }\n309 \n310     public function testReduceShouldApplyCallableToSeveralElements()\n311     {\n312         $sut = $this->getCollection();\n313         $sut->append($this);\n314         $sut->append($this);\n315         $result = $sut->reduce(function (CollectionTest $element, $accumulator) {\n316             return $accumulator + 1;\n317         }, 0);\n318         $this->assertEquals(2, $result);\n319     }\n320 \n321     public function testCollectShouldReturnInstanceOfCollection()\n322     {\n323         $sut = Collection::collect([\n324             $this\n325         ]);\n326         $this->assertEquals(CollectionTest::class, $sut->getType());\n327     }\n328 \n329     public function testCollectShouldFailWithExceptionIfEmptyArray()\n330     {\n331         $this->expectException(\\InvalidArgumentException::class);\n332         Collection::collect([]);\n333     }\n334 \n335     public function testCollectShouldPopulateCollectionWithOneElement()\n336     {\n337         $sut = Collection::collect([\n338             $this\n339         ]);\n340         $this->assertEquals(1, $sut->count());\n341     }\n342 \n343     public function testCollectShouldPopulateCollectionWithSeveralElements()\n344     {\n345         $sut = Collection::collect([\n346             $this,\n347             $this\n348         ]);\n349         $this->assertEquals(2, $sut->count());\n350     }\n351 \n352     public function testShouldFailWithExceptionsWhenInvalidTypeFound()\n353     {\n354         $this->expectException(\\UnexpectedValueException::class);\n355         Collection::collect([\n356             $this,\n357             new \\stdClass()\n358         ]);\n359     }\n360 \n361     public function testShouldMapEmptyCollectionToEmptyArray()\n362     {\n363         $sut = $this->getCollection();\n364         $this->assertEquals([], $sut->toArray());\n365     }\n366 \n367     public function testShouldReturnCollectionAsArray()\n368     {\n369         $sample = [$this];\n370         $sut = Collection::collect($sample);\n371         $this->assertEquals($sample, $sut->toArray());\n372     }\n373 \n374     public function testShouldMapOneElementCollectionToArray()\n375     {\n376         $sut = $this->getCollection();\n377         $sut->append($this);\n378         $this->assertEquals(['mapped'], $sut->toArray(function(CollectionTest $eleme\\\n379 nt) {\n380             return 'mapped';\n381         }));\n382     }\n383 \n384     public function testShouldMapSeveralElementsCollectionToArray()\n385     {\n386         $sut = $this->getCollection();\n387         $sut->append($this);\n388         $sut->append($this);\n389         $this->assertEquals(['mapped', 'mapped'], $sut->toArray(function(CollectionT\\\n390 est $element) {\n391             return 'mapped';\n392         }));\n393     }\n394 \n395     public function testShouldTellCollectionType()\n396     {\n397         $sut = Collection::of(CollectionTest::class);\n398         $this->assertEquals(CollectionTest::class, $sut->getType());\n399     }\n400 \n401     public function testShouldTellIfCollectionIsEmpty()\n402     {\n403         $sut = $this->getCollection();\n404         $this->assertTrue($sut->isEmpty());\n405     }\n406 \n407     public function testShouldTellIfCollectionIsNotEmpty()\n408     {\n409         $sut = $this->getCollection();\n410         $sut->append($this);\n411         $this->assertFalse($sut->isEmpty());\n412     }\n413 \n414     public function isTarget()\n415     {\n416         return isset($this->target);\n417     }\n418 }\n419 \n420 class MappedObject\n421 {\n422 \n423 }\n

\n\n\n\n\n

Apéndices

\n\n

\nPHPUnit Instrucciones básicas para instalar y configurar phpunit en un proyecto.
\nPHPSpec Instrucciones básicas para instalar y configurar phpspec en un proyecto, junto con una pequeña guía para entender sus similitudes y diferencias con phpunit.

\n\n\n

Apéndice 1: PhpUnit

\n\n

PhpUnit es el framework de test por excelencia de PHP. Pertenece a la familia xUnit y con él puedes desarrollar todo tipo de tests.

\n\n

Instalación

\n\n

Nos situamos dentro de la carpeta del proyecto, creándola si es necesario:

\n\n

1 mkdir dojo\n2 cd dojo\n

\n\n\n\n

Dentro del proyecto asumimos la convención de tener las las carpetas src y tests

\n\n

1 mkdir src\n2 mkdir tests\n

\n\n\n\n

Si no lo hemos hecho antes, iniciamos el proyecto mediante composer init y como primera dependencia requerimos phpunit.

\n\n

1 composer init\n2 # Fill in with the data needed\n3 composer require --dev phpunit/phpunit\n

\n\n\n\n

Por último, configuraremos los namespaces del proyecto en composer.json, que quedará más o menos así:

\n\n

 1 {\n 2   \"name\": \"talkingbit/dojo\",\n 3   \"description\": \"A simple space to practice testing\",\n 4   \"minimum-stability\": \"dev\",\n 5   \"license\": \"MIT\",\n 6   \"type\": \"library\",\n 7   \"config\": {\n 8     \"bin-dir\": \"bin\"\n 9   },\n10   \"authors\": [\n11     {\n12       \"name\": \"Fran Iglesias\",\n13       \"email\": \"franiglesiad@mac.com\"\n14     }\n15   ],\n16   \"require-dev\": {\n17     \"phpunit/phpunit\": \"^7.4@dev\"\n18   },\n19   \"autoload\": {\n20     \"psr-4\": {\n21       \"TalkingBit\\\\Dojo\\\\\": \"src/\"\n22     }\n23   },\n24   \"autoload-dev\": {\n25     \"psr-4\": {\n26       \"Tests\\\\TalkingBit\\\\Dojo\\\\\": \"tests/\"\n27     }\n28   }\n29 }\n

\n\n\n\n

También hemos añadido la clave config, con bin-dir, de este modo, los paquetes como phpunit y otros crearán un alias de su ejecutable en la carpeta bin, con lo que podremos lanzarlos fácilmente con bin/phpunit.

\n\n

Después de este cambio puedes hacer un composer install o un composer dump-autoload, para ponerte en marcha.

\n\n

1 composer install\n

\n\n\n\n

Configuración básica

\n\n

phpunit necesita un poco de configuración, así que vamos a prepararla ejecutando lo siguiente. Es un interactivo y normalmente nos servirán las respuestas por defecto.

\n\n

1 bin/phpunit --generate-configuration\n

\n\n\n\n

Esto generará un archivo de configuración por defecto phpunit.xml (más información en este artículo). Normalmente hago un pequeño cambio para poder tener medida de cobertura en cualquier código y no tener que pedir explícitamente en cada test, poniendo el parámetro forceCoversAnnotation a false:

\n\n

 1 <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n 2 <phpunit xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n 3          xsi:noNamespaceSchemaLocation=\"https://schema.phpunit.de/7.4/phpunit.xsd\"\n 4          bootstrap=\"vendor/autoload.php\"\n 5          forceCoversAnnotation=\"false\"\n 6          beStrictAboutCoversAnnotation=\"true\"\n 7          beStrictAboutOutputDuringTests=\"true\"\n 8          beStrictAboutTodoAnnotatedTests=\"true\"\n 9          verbose=\"true\">\n10     <testsuites>\n11         <testsuite name=\"default\">\n12             <directory suffix=\"Test.php\">tests</directory>\n13         </testsuite>\n14     </testsuites>\n15 \n16     <filter>\n17         <whitelist processUncoveredFilesFromWhitelist=\"true\">\n18             <directory suffix=\".php\">src</directory>\n19         </whitelist>\n20     </filter>\n21 </phpunit>\n

\n\n\n\n

Si es necesario, añadimos el control de versiones:

\n\n

1 git init\n

\n\n\n\n

Y con esto, podemos empezar.

\n\n\n

Apéndice 2: PhpSpec

\n\n

Phpspec es un framework para BDD (Behavior Driven Design). Se trata de una variante de TDD que se centra en la descripción del comportamiento de los objetos mediante ejemplos.

\n\n

Principalmente es una herramienta de diseño, y no tanto de testing, aunque es válida para test unitarios, y en cualquier caso no puede usarse para test de integración o de aceptación. Para esos casos utilizaríamos behat, una herramienta de la misma familia.

\n\n

Instalación

\n\n

Nos situamos dentro de la carpeta del proyecto, creándola si es necesario:

\n\n

1 mkdir dojo\n2 cd dojo\n

\n\n\n\n

Dentro del proyecto asumimos la convención de tener las las carpetas src y spec. Esta última se crea automáticamente, por lo que este paso es opcional.

\n\n

1 mkdir src\n2 mkdir spec\n

\n\n\n\n

Si planeas usar plantillas de código (ver más abajo) debes crear la carpeta .phpspec en la raíz del proyecto.

\n\n

1 mkdir .phpspec\n

\n\n\n\n

Si no lo hemos hecho antes, iniciamos el proyecto mediante composer init y como primera dependencia requerimos phpspec.

\n\n

1 composer init\n2 # Fill in with the data needed\n3 composer require --dev phpspec/phpspec\n

\n\n\n\n

Configuración inicial

\n\n

En cuanto a la configuración, este sería un buen composer.json mínimo para usar phpspec con soporte de PSR-4. También puedes configurar el autoload para que use PSR-0.

\n\n

 1 {\n 2   \"name\": \"talkingbit/dojo\",\n 3   \"description\": \"A simple space to practice testing\",\n 4   \"minimum-stability\": \"dev\",\n 5   \"license\": \"MIT\",\n 6   \"type\": \"library\",\n 7   \"config\": {\n 8     \"bin-dir\": \"bin\"\n 9   },\n10   \"authors\": [\n11     {\n12       \"name\": \"Fran Iglesias\",\n13       \"email\": \"franiglesiad@mac.com\"\n14     }\n15   ],\n16   \"require-dev\": {\n17     \"phpspec/phpspec\": \"5.0.x-dev\"\n18   },\n19   \"autoload\": {\n20     \"psr-4\": {\n21       \"TalkingBit\\\\Dojo\\\\\": \"src/\"\n22     }\n23   },\n24   \"autoload-dev\": {\n25     \"psr-0\": {\n26       \"\": \"src/\"\n27     },\n28     \"psr-4\": {\n29       \"Tests\\\\TalkingBit\\\\Dojo\\\\\": \"tests/\"\n30     }\n31   }\n32 }\n

\n\n\n\n

Si basas el autoload en PSR-0 no necesitarías nada más, pero como nosotros lo vamos a configurar para PSR-4, aquí tienes un archivo phpspec.yml de ejemplo (y que podríamos ampliar más adelante para dar soporte a otras características).

\n\n

1 suites:\n2     example_suite:\n3         namespace: TalkingBit\\Dojo\n4         psr4_prefix: TalkingBit\\Dojo\n5         spec_prefix: spec\n6         src_path: '%paths.config%/src'\n7         spec_path: '%paths.config%'\n

\n\n\n\n

\nexample_suite: un nombre para la suite de specs que queramos configurar.\n** namespace: es la raíz del namespace que hayas definido en composer.json bajo autoload: psr-4.
\npsr4-prefix: en principio, coincide con la anterior, pero se refiere a la ruta que debe usar en el sistema de archivos para guardar el código.
\nspec_prefix: es el nombre de la carpeta que contiene los archivos de especificaciones, que se nombran con el sufijo *Spec.php.
\nsrc_path: es la ruta bajo la que se guardará el código generado. En el ejemplo %paths.config% apunta a la raíz del proyecto y la carpeta es src.
\nspec_path es la ruta bajo la que se almacenarán las especificaciones, creándose en ella la carpeta definida en spec_prefix.

\n\n

Para nota: plantillas

\n\n

phpspec es capaz de ayudarnos con los pasos más tediosos de la generación de código, para lo que utiliza un sistema de plantillas que se pueden personalizar guardando archivos con extensión .tpl en una carpeta .phpspec en la raíz del proyecto. Por ejemplo:

\n\n

class.tpl

\n\n

1 <?php\n2 declare (strict_types = 1);%namespace_block%\n3 \n4 class %name%\n5 {\n6 }\n

\n\n\n\n

specification.tpl

\n\n

 1 <?php\n 2 \n 3 namespace %namespace%;\n 4 \n 5 use %subject%;\n 6 use PhpSpec\\ObjectBehavior;\n 7 use Prophecy\\Argument;\n 8 \n 9 class %name% extends ObjectBehavior\n10 {\n11     public function it_is_initializable()\n12     {\n13         $this->shouldHaveType(%subject_class%::class);\n14     }\n15 }\n

\n\n\n\n

Specification by example

En el fondo, las especificaciones mediante ejemplos son equivalentes a los asserts de PHPUnit, pero la forma particular de realizarlas nos ayuda a ver la clase en cuanto a su comportamiento.

\n\n

Por ejemplo, en PHPUnit escribiríamos un test como este:

\n\n

1 public function testShouldCalculateThePriceWithDiscount()\n2 {\n3     $price = new Price(100);\n4     $discountedPrice = $price->minusDiscountPercent(15);\n5     $this->assertEquals(85, $discountedPrice);\n6 }\n

\n\n\n\n

En phpspec, lo equivalente sería escribir el siguiente ejemplo:

\n\n

1 public function it_should_calculate_the_price_with_discount()\n2 {\n3     $this->beConstructedWith(100);\n4     $this->$price->minusDiscountPercent(15)->shouldBe(85);\n5 }\n

\n\n\n\n

Veamos las diferencias una a una:

\n\n

En phpspec

\n\n

Los TestCase se llaman Specification.
Los tests se llaman ejemplos y se nombrar comenzando por it_ o its_.
En una Specification $this es un proxy a nuestro Subject Under Test.
En lugar de assertions usamos matchers, que verifican lo que devuelve el método probado.

\n\n

Además de estas diferencias que se pueden observar, en phpspec:

\n\n

No se pueden aplicar matchers sobre otra cosa que no sean los métodos del Subject Under Test, dado que $this es un proxy que captura la salida del método original y nos permite testearla.
Se pueden definir TestDoubles de forma muy sencilla que son generados mediante el framework Prophecy. Basta indicarlos como parámetros en los ejemplos, tipados con la interfaz o clase que queremos doblar.

\n\n

Primera especificación

\n\n

Para ahorrarnos un poco de trabajo phpspec se maneja con dos comandos principales:

\n\n

\ndescribe: con el que inicializamos la descripción o spec de una clase.
\nrun: con el que ejecutamos los tests.

\n\n

Describe

\n\n

El primero es describe y nos permite iniciar la descripción de una clase a través de ejemplos.

\n\n

Tomando como punto de partida la configuración que acabamos de hacer, vamos a imaginar que queremos describir una clase DojoDomainCustomerCustomer. Lo haríamos así:

\n\n

1 bin/phpspec describe Dojo/Domain/Customer/Customer\n

\n\n\n\n

Una forma alternativa que usa la sintaxis de los namespace es:

\n\n

1 bin/phpspec describe 'Dojo\\Domain\\Customer\\Customer'\n

\n\n\n\n

Al ejecutar este comando se creará una especificación inicial para esta clase, que se guardará en el archivo spec/Dojo/Domain/Customer/CustomerSpec.php.

\n\n

El programa devolverá el siguiente resultado:

\n\n

1 Specification for Dojo\\Domain\\Customer\\Customer created in /Users/frankie/Sites/hlz/\\\n2 spec/Domain/Customer/CustomerSpec.php.\n

\n\n\n\n

Y la Spec, creada en la ruta indicada, tendrá esta pinta:

\n\n

spec/Domain/Customer/CustomerSpec.php

\n\n

 1 <?php\n 2 \n 3 namespace spec\\Dojo\\Domain\\Customer;\n 4 \n 5 use Dojo\\Domain\\Customer\\Customer;\n 6 use PhpSpec\\ObjectBehavior;\n 7 use Prophecy\\Argument;\n 8 \n 9 class CustomerSpec extends ObjectBehavior\n10 {\n11     function it_is_initializable()\n12     {\n13         $this->shouldHaveType(Customer::class);\n14     }\n15 }\n

\n\n\n\n

Cosas interesantes:

\n\n

La clase CustomerSpec viene a ser el equivalente de un TestSuite de PHPUnit, pero está creado de tal manera que $this es usado como proxy a la clase Customer que es la que estamos especificando. Dicho de otra forma: $this es nuestro SUT (Subject Under Test).
El método it_is_initializable es un ejemplo. Equivale a un test. Se escriben en snake_case y deben comenzar por it o its.
En el método podemos ver un matcher, un concepto similar a una aserción, y que, en este caso es shouldHaveType (el equivalente assertInstanceOf).

\n\n

Run

\n\n

Una vez que hemos escrito nuestra primera Spec, el siguiente paso es ejecutarla, como corresponde a una metodología TDD. Evidentemente, como nos exige el ciclo Red-Green-Refactor de TDD, no hemos creado todavía la clase Customer, pero eso llegará en su momento.

\n\n

1 bin/phpspec run\n

\n\n\n\n

El comando anterior ejecutará todas las Spec que pueda encontrar. Si queremos ser más precisos podemos indicarlo de varias maneras.

\n\n

Por ejemplo, usando el namespace (las comillas son obligatorias):

\n\n

1 bin/phpspec run 'Dojo\\Domain\\Customer\\Customer'\n

\n\n\n\n

O bien, la ruta completa al archivo de la Spec:

\n\n

1 bin/phpspec run spec/Dojo/Domain/Customer/CustomerSpec.php\n

\n\n\n\n

O bien, indicando una ruta en la que esté incluida nuestra Spec:

\n\n

1 bin/phpspec run spec/Dojo/Domain/\n

\n\n\n\n

En cualquier caso, el test fallará y nos devolverá el siguiente resultado (los detalles pueden cambiar un poco dependiendo de la forma de invocarla):

\n\n

 1 Dojo/Domain/Customer/Customer                                                   \n 2   11  - it is initializable\n 3       class Dojo\\Domain\\Customer\\Customer does not exist.\n 4 \n 5                                       100%                                       1\n 6 1 specs\n 7 1 example (1 broken)\n 8 6ms\n 9 \n10                                                                                 \n11   Do you want me to create `Dojo\\Domain\\Customer\\Customer` for you?             \n12                                                                          [Y/n] \n

\n\n\n\n

Fíjate que al final se ofrece a crear la clase descrita por ti, para lo cual bastará con responder y.

\n\n

1 Class Dojo\\Domain\\Customer\\Customer created in /Users/frankie/Sites/hlz/src/Domain/C\\\n2 ustomer/Customer.php.\n3 \n4                                       100%                                       1\n5 1 specs\n6 1 example (1 passed)\n7 7ms\n

\n\n\n\n

¿Qué ha pasado aquí?

\n\n

Pues que phpspec ha creado la clase descrita en el lugar adecuado y ha vuelto a ejecutar la Spec, que ahora está en verde (en este artículo no está coloreada la salida).

\n\n

La clase ha sido creada así:

\n\n

spec/Domain/Customer/CustomerSpec.php

\n\n

1 <?php\n2 declare (strict_types = 1);\n3 \n4 namespace Dojo\\Domain\\Customer;\n5 \n6 class Customer\n7 {\n8 }\n

\n\n\n\n

En general, cada vez que phpspec se encuentre con algo que puede ayudarnos a crear nos ofrecerá la opción. Como veremos más adelante, eso incluye los nuevos métodos que podamos añadir a nuestra clase, así como Interfaces de colaboradores. Pero ahora no adelantemos acontecimientos.

\n\n

A partir de ahora, nuestra tarea será ir creando nuevos ejemplos de test que fallen, ejecutarlos y, cuando fallen, implementar el código mínimo necesario para pasar.

Notas

1Lo que podría ser una forma de aproximarse al problema que señalaba al principio de no cubrir correctamente algunos casos en los tests de integración.↩

\n\n

2Los Mocks me plantean un problema, pues se llevan las aserciones fuera del flujo Given-When-Then del test hasta el punto de tener tests sin aserciones explícitas y, de hecho, acoplan el test a la implementación del subject under test, algo que me fastidia sobremanera porque revientan cuando necesitas hacer un cambio.↩

\n\n\n

\n\n

\n\n","tocStructure",[520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646],{"_75":76,"_42":77,"_69":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":85,"_69":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":91,"_69":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":94,"_69":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":97,"_69":-5,"_78":98,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":100,"_69":-5,"_78":101,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":103,"_69":-5,"_78":104,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":106,"_69":-5,"_78":107,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":109,"_69":-5,"_78":110,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":112,"_69":-5,"_78":113,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":115,"_69":-5,"_78":116,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":119,"_69":-5,"_78":120,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":122,"_69":-5,"_78":123,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":125,"_69":-5,"_78":126,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":128,"_69":-5,"_78":129,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":131,"_69":-5,"_78":132,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":134,"_69":-5,"_78":135,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":137,"_69":-5,"_78":138,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":140,"_69":-5,"_78":141,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":143,"_69":-5,"_78":144,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":147,"_69":-5,"_78":148,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":150,"_69":-5,"_78":151,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":153,"_69":-5,"_78":154,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":156,"_69":-5,"_78":157,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":159,"_69":-5,"_78":160,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":163,"_69":-5,"_78":164,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":166,"_69":-5,"_78":167,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":169,"_69":-5,"_78":170,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":172,"_69":-5,"_78":173,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":175,"_69":-5,"_78":176,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":178,"_69":-5,"_78":179,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":181,"_69":-5,"_78":182,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":184,"_69":-5,"_78":185,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":188,"_69":-5,"_78":189,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":192,"_69":-5,"_78":193,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":195,"_69":-5,"_78":196,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":198,"_69":-5,"_78":199,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":201,"_69":-5,"_78":202,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":204,"_69":-5,"_78":205,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":207,"_69":-5,"_78":208,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":211,"_69":-5,"_78":212,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":214,"_69":-5,"_78":215,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":217,"_69":-5,"_78":218,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":220,"_69":-5,"_78":221,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":223,"_69":-5,"_78":224,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":226,"_69":-5,"_78":227,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":229,"_69":-5,"_78":230,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":232,"_69":-5,"_78":233,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":236,"_69":-5,"_78":237,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":239,"_69":-5,"_78":240,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":242,"_69":-5,"_78":243,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":245,"_69":-5,"_78":246,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":248,"_69":-5,"_78":249,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":251,"_69":-5,"_78":252,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":255,"_69":-5,"_78":256,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":258,"_69":-5,"_78":259,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":261,"_69":-5,"_78":262,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":264,"_69":-5,"_78":265,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":267,"_69":-5,"_78":268,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":270,"_69":-5,"_78":271,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":274,"_69":-5,"_78":275,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":277,"_69":-5,"_78":278,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":280,"_69":-5,"_78":281,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":283,"_69":-5,"_78":284,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":287,"_69":-5,"_78":288,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":290,"_69":-5,"_78":291,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":293,"_69":-5,"_78":294,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":296,"_69":-5,"_78":297,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":299,"_69":-5,"_78":300,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":302,"_69":-5,"_78":303,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":306,"_69":-5,"_78":307,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":309,"_69":-5,"_78":310,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":312,"_69":-5,"_78":313,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":316,"_69":-5,"_78":317,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":319,"_69":-5,"_78":320,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":322,"_69":-5,"_78":323,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":325,"_69":-5,"_78":326,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":328,"_69":-5,"_78":329,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":331,"_69":-5,"_78":332,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":334,"_69":-5,"_78":335,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":337,"_69":-5,"_78":338,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":340,"_69":-5,"_78":341,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":343,"_69":-5,"_78":344,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":346,"_69":-5,"_78":347,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":349,"_69":-5,"_78":350,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":353,"_69":-5,"_78":354,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":356,"_69":-5,"_78":357,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":359,"_69":-5,"_78":360,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":362,"_69":-5,"_78":363,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":365,"_69":-5,"_78":366,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":368,"_69":-5,"_78":369,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":371,"_69":-5,"_78":372,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":374,"_69":-5,"_78":375,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":377,"_69":-5,"_78":378,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":381,"_69":-5,"_78":382,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":384,"_69":-5,"_78":385,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":387,"_69":-5,"_78":388,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":390,"_69":-5,"_78":391,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":393,"_69":-5,"_78":394,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":397,"_69":-5,"_78":398,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":400,"_69":-5,"_78":401,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":403,"_69":-5,"_78":404,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":406,"_69":-5,"_78":407,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":409,"_69":-5,"_78":410,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":412,"_69":-5,"_78":413,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":416,"_69":-5,"_78":417,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":419,"_69":-5,"_78":420,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":422,"_69":-5,"_78":423,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":425,"_69":-5,"_78":426,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":428,"_69":-5,"_78":429,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":431,"_69":-5,"_78":432,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":434,"_69":-5,"_78":435,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":438,"_69":-5,"_78":439,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":441,"_69":-5,"_78":442,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":444,"_69":-5,"_78":445,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":447,"_69":-5,"_78":448,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":450,"_69":-5,"_78":451,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":453,"_69":-5,"_78":454,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":457,"_69":-5,"_78":458,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":461,"_69":-5,"_78":462,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":464,"_69":-5,"_78":465,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":467,"_69":-5,"_78":468,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":461,"_69":-5,"_78":471,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":473,"_69":-5,"_78":474,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":476,"_69":-5,"_78":477,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_42":479,"_69":-5,"_78":480,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_42":482,"_69":-5,"_78":483,"_71":80,"_87":-5,"_88":-5,"_89":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]