Prólogo

Cómo usar este libro

No hay una forma correcta, o incorrecta si vamos a eso, de leer este libro. Todo depende de tus intereses.

Para empezar, se estructura en cuatro partes principales que pueden leerse separadamente:

En la primera se introducen los conceptos básicos de TDD, así como algunas estrategias para aprender a usar e introducir esta disciplina en tu práctica.

En la segunda, se presenta una selección de katas o ejercicios de código con la que se explican en profundidad los conceptos y técnicas de Test Driven Development en su definición clásica. Van desde las que son muy conocidas hasta algunas propias.

Cada una de las katas se organiza de la siguiente forma:

• Un capítulo teórico dedicado a un aspecto destacado de TDD puesto de relieve por esa kata y sobre el que he incidido especialmente al resolverla.
• Una introducción a la kata, su origen si es conocido, su enunciado y una serie de recomendaciones o puntos de interés sobre la misma.
• Una solución desarrollada en un lenguaje de programación diferente y explicada en detalle. Hay un repositorio con soluciones a las katas en varios lenguajes.

La tercera parte introduce la metodología outside-in TDD. Outside-in TDD es una propuesta en la que se busca potenciar la fase de diseño, y que se puede aplicar al desarrollo en proyectos reales.

La cuarta parte está orientada a mostrar un ejemplo de un proyecto realista y cómo se puede incorporar TDD en las distintas etapas de desarrollo y mantenimiento, desde la creación de un producto mínimo viable (MVP) a la resolución de defectos y la incorporación de nuevas características.

Si estás buscando un manual para aprender TDD desde cero, mi recomendación sería leerlo en orden. Los ejercicios de código están dispuestos para introducir los conceptos en una progresión determinada, a la que he llegado por experiencia personal y cuando he enseñado a otras personas a usar TDD.

Al principio, puede parecerte que los ejercicios de TDD son muy triviales y poco realistas. Ten presente que el nombre de Kata no es casual. Una Kata, en artes marciales, es un ejercicio repetitivo que se ejecuta hasta automatizar sus movimientos y más allá. Si practicas algún deporte habrás realizado decenas de ejercicios destinados a ganar flexibilidad, fuerza, movilidad y automatismos, sin que tengan una aplicación directa en ese deporte concreto. Las Katas de TDD tienen esa misma función: preparan tu cerebro para automatizar ciertas rutinas, generar determinados hábitos y conseguir detectar patrones particulares en el proceso de desarrollo.

Posiblemente, el enfoque outside-in te parezca mucho más aplicable a tu trabajo diario. De hecho, es una forma de desarrollar proyectos usando TDD. Sin embargo, una base sólida en TDD clásico es fundamental para tener éxito usando este enfoque. Outside-in está muy próximo al Behavior Driven Development.

Como se ha mencionado antes, las distintas partes y ejercicios son relativamente independientes. Si ya tienes cierta experiencia con la disciplina del Test Driven Development, puedes ir directamente a los apartados o ejercicios que te interesen. Con frecuencia descubrirás algo nuevo. Una de las cosas que me he encontrado es que siempre acaba apareciendo alguna idea nueva aunque hayas realizado el mismo ejercicio decenas de veces.

Si buscas cómo introducir TDD en tu proceso de trabajo o en el de tu equipo, es posible que vayas directamente a la parte sobre TDD en la vida real. Es la que tiene, por así decir, más dependencia en conocimientos y experiencia previa. En ese caso, si consideras que te falta soltura en TDD posiblemente debas echar un vistazo a otras partes del libro.

Para alcanzar un buen nivel de desempeño en TDD deberías practicar los ejercicios muchas veces. No hablo de tres o cuatro, estoy hablando de decenas de veces, en distintos momentos de tu vida profesional e, idealmente, en distintos lenguajes. Existen varios repositorios de katas en los que encontrar ejercicios, y puedes inventar o descubrir los tuyos propios.

También es recomendable ver cómo otras personas realizan estos ejercicios. En la web están disponibles montones de ejemplos de Katas realizadas en una variedad de lenguajes de programación, y es una gran forma de contrastar tus soluciones y tu proceso.

Y, por supuesto, pero no en último lugar, una de las mejores formas de aprender es practicar con otras personas. Ya sea en proyectos de trabajo, formaciones o comunidades de práctica. Debatir en vivo las soluciones, el tamaño de los pasos, el comportamiento a testear, contribuirá a pulir y fortalecer vuestro proceso de desarrollo.

Asunciones

Para este libro se asumen algunos supuestos:

• Que tienes cierta experiencia en algún lenguaje de programación y un entorno de testing de ese lenguaje. En otras palabras: sabes escribir y ejecutar tests. No importa que tu lenguaje preferido no esté contemplado en este libro.
• Los ejemplos del libro están en varios lenguajes y en la medida de lo posible se evita usar características muy específicas. De hecho, soy novato en muchos de ellos, por lo que el código puede parecer muy simplón. Por otro lado, esto es algo deseable en TDD, como verás a lo largo del libro.
• Tienes claro que el objetivo de los ejercicios de código no es tanto resolver el problema planteado como tal, que finalmente se resuelve, sino el proceso por el que llegamos a esa solución.
• Entiendes que no existe una solución única, ni un camino preciso en la resolución de las katas. Si tu solución no coincide con la planteada en este libro, no es ningún problema.

Disclaimer

Las soluciones propuestas a las katas se proporcionan como ejemplos explicados de los procesos de razonamiento que se podrían seguir. No son soluciones ideales. Cuando realices tu versión podrías seguir un proceso completamente diferente que podría ser tan válido o más que el presentado aquí.

Por otra parte, sucesivas ejecuciones de una misma kata por la misma persona podrían llevarla a soluciones y recorridos diferentes. Ese es uno de sus beneficios: al acostumbrarnos a ciertos patrones de pensamiento y automatizarlos podemos prestar atención a más detalles cada vez y encontrar puntos de intervención más interesantes.

Igualmente, a medida que se incrementa nuestra fluidez en un lenguaje de programación, las implementaciones que logramos pueden ser mejores y más elegantes.

Al preparar las katas presentadas en este libro he realizado varias versiones, incluso en distintos lenguajes a fin de encontrar los recorridos más interesantes o incluso provocar algunos problemas que me interesaba poner de manifiesto. La solución que he decidido publicar en cada caso está cargada hacia algún punto que me interesaba acentuar del proceso de TDD por lo que podría no ser la óptima.

Es decir, en cierto modo las katas tienen trampa, se trata de forzar las cosas hasta cierto punto para lograr un objetivo didáctico.

En otro orden de cosas, he aprovechado este proyecto para forzarme a experimentar con lenguajes de programación diferentes. En algunos casos, son lenguajes nuevos para mí o con los que no estoy acostumbrado a trabajar, por lo que es posible que las implementaciones sean especialmente toscas o que no incluyan algunas de sus características más específicas y óptimas.

Conceptos básicos de TDD

En esta primera parte, introduciremos los conceptos básicos para entender qué es Test Driven Development y en qué se diferencia de otras disciplinas y metodologías que utilizan tests. También hablaremos de cómo puedes aprender TDD, ya sea individualmente o en un equipo o comunidad de práctica.

En el primer capítulo se hace una introducción general al proceso de test driven development.

El capítulo sobre conceptos básicos es un glosario de términos que usaremos a lo largo del libro.

Finalmente, el capítulo sobre coding-dojo y katas propone algunas ideas sencillas para empezar a practicar en equipo o individualmente.

1 ¿Qué es TDD y por qué debería importarme?

Test Driven Development es una metodología de desarrollo de software en la que se escriben tests para guiar la escritura del código de producción.

Los tests especifican de manera formal, ejecutable y mediante ejemplos, los comportamientos que debe realizar el software que estamos programando, definiendo pequeños objetivos que, al ser superados, nos permiten construir el software de forma progresiva, segura y estructurada.

Aunque hablemos de tests, no estamos hablando de Quality Assurance (en adelante: QA), aunque al trabajar con metodología TDD conseguimos el efecto secundario de hacernos con una suite de tests unitarios que es válida y que tiene la máxima cobertura posible. De hecho, lo normal es que una parte de los tests creados en TDD sean innecesarios para una batería comprensiva de tests de regresión, por lo que es habitual eliminarlos a medida que nuevos tests los convierten en redundantes.

Es decir: tanto TDD como QA se basan en la utilización de los tests como herramientas, pero este uso se diferencia en varios aspectos. Específicamente, en TDD:

• El test se escribe antes de que el software que ejecuta siquiera exista.
• Los tests son muy pequeños y su objetivo es forzar la escriture del código de producción mínimo necesario para que el test pase, que tiene el efecto de implementar el comportamiento definido por el test.
• Los tests guían el desarrollo del código y el proceso contribuye al diseño del sistema.

En TDD los tests se definen como especificaciones ejecutables del comportamiento de la unidad de software considerada, mientras que en QA el test es una herramienta de verificación de ese mismo comportamiento. Expresado de manera más sencilla:

• Cuando hacemos QA pretendemos comprobar que el software que hemos escrito se comporta según los requisitos definidos.
• Cuando hacemos TDD escribimos software para que cumpla los requisitos definidos, uno por uno, de modo que terminamos con un producto que los cumple.

La metodología Test Driven Development

Aunque a lo largo del libro vamos a desarrollar este apartado en profundidad presentaremos brevemente lo esencial de la metodología.

En TDD los tests se escriben en una forma que podríamos considerar como de diálogo con el código de producción. Este diálogo, las normas que lo regulan y los ciclos que esta forma de interactuar con el código genera los practicaremos con la primera kata del libro: FizzBuzz.

Básicamente se trata de:

• Escribir un test que falla
• Escribir código que haga que el test pase
• Mejorar la estructura del código (y del test)

Escribir un test que falle

Una vez que tenemos claro la pieza de software en la que vamos a trabajar y la funcionalidad que queremos implementar, lo primero es definir un primer test muy pequeño que fallará sin remedio porque ni siquiera existe un archivo que contenga el código de producción necesario para que se pueda ejecutar. Aunque es algo que trataremos en todas las katas, en la kata NIF profundizaremos en estrategias que nos servirán para decidir los primeros tests.

He aquí un ejemplo en Go:

// roman/roman_test.go
package roman

import "testing"

func TestRomanNumeralsConversion(t *testing.T) {
	roman := decToRoman(1)

	if roman != "I" {
		t.Errorf(
			"Decimal %d should convert to %s, but found %s",
			 1,
			 "I", 
			 roman
		 )
	}
}

Aunque podemos predecir que el test ni siquiera podrá compilarse o interpretarse, lo intentaremos ejecutar igualmente. En TDD es fundamental ver que los tests fallan, no basta con suponerlo. Nuestro trabajo es hacer que el test falle por la razón correcta y luego hacerlo pasar escribiendo código de producción.

# tddbook-go/roman [tddbook-go/roman.test]
./roman_test.go:6:11: undefined: decToRoman

Compilation finished with exit code 2

El mensaje de error nos indicará qué es lo que tenemos que hacer a continuación. Nuestro objetivo a corto plazo es hacer desaparecer ese mensaje de error y los que puedan venir después, uno por uno.

package roman

import "testing"

func TestRomanNumeralsConversion(t *testing.T) {
	roman := decToRoman(1)

	if roman != "I" {
		t.Errorf(
			"Decimal %d should convert to %s, but found %s",
			1,
			"I",
			roman
		)
	}
}

func decToRoman(decimal int) string {
	
}

Por ejemplo, al introducir la función decToRoman, el error cambiará. Ahora nos dice que debería devolver un valor:

# tddbook-go/roman [tddbook-go/roman.test]
./roman_test.go:16:1: missing return at end of function

Compilation finished with exit code 2

Podría ocurrir incluso que sea un mensaje inesperado, como que hemos querido cargar la clase Book y resulta que hemos creado un archivo brok por error. Por eso es tan importante lanzar el test y ver si falla y cómo falla exactamente.

package roman

import "testing"

func TestRomanNumeralsConversion(t *testing.T) {
	roman := decToRoman(1)

	if roman != "I" {
		t.Errorf(
			"Decimal %d should convert to %s, but found %s",
			1,
			"I",
			roman
		)
	}
}

func decToroman(decimal int) string {
	
}

Este código da lugar al siguiente mensaje:

# tddbook-go/roman [tddbook-go/roman.test]
./roman_test.go:6:11: undefined: decToRoman
./roman_test.go:16:1: missing return at end of function

Compilation finished with exit code 2

Este error nos indica que hemos escrito incorrectamente el nombre de la función, así que primero lo corregimos:

package roman

import "testing"

func TestRomanNumeralsConversion(t *testing.T) {
	roman := decToRoman(1)

	if roman != "I" {
		t.Errorf(
			"Decimal %d should convert to %s, but found %s", 
			1, 
			"I", 
			roman
		)
	}
}

func decToRoman(decimal int) string {
	
}

Y podemos continuar. Como el test dice que espera que al pasar 1 a la función nos devuelva “I”, el test fallido debería indicarnos que no coincide el resultado recibido con el esperado. Pero, de momento, el test nos está diciendo que la función no devuelve nada. Todavía es un fallo de compilación y todavía no es la razón correcta para fallar.

# tddbook-go/roman [tddbook-go/roman.test]
./roman_test.go:16:1: missing return at end of function

Compilation finished with exit code 2

Para conseguir que el test falle por la razón que esperamos, tenemos que hacer que la función devuelva un string, aunque sea vacío:

package roman

import "testing"

func TestRomanNumeralsConversion(t *testing.T) {
	roman := decToRoman(1)

	if roman != "I" {
		t.Errorf(
			"Decimal %d should convert to %s, but found %s",
			1, 
			"I", 
			roman
		)
	}
}

func decToRoman(decimal int) string {
	return ""
}

Y este cambio hace que el error ahora sea uno relacionado con que el test no pasa, pues no obtiene el resultado que espera. Esta es la razón correcta para fallar, la que nos forzará a escribir código de producción que haga pasar el test:

=== RUN   TestRomanNumeralsConversion
--- FAIL: TestRomanNumeralsConversion (0.00s)
    roman_test.go:9: Decimal 1 should convert to I, but found 
FAIL

Process finished with exit code 1

Y así estaríamos listas para dar el siguiente paso:

Escribir código que haga que el test pase

Como respuesta al resultado anterior, se escribe el código de producción necesario para que el test pase, pero nada más. Siguiendo con nuestro ejemplo:

package roman

import "testing"

func TestRomanNumeralsConversion(t *testing.T) {
	roman := decToRoman(1)

	if roman != "I" {
		t.Errorf(
			"Decimal %d should convert to %s, but found %s", 
			1, 
			"I", 
			roman
		)
	}
}

func decToRoman(decimal int) string {
	return "I"
}

Tras hacer pasar el primer test podemos empezar creando el archivo que contendrá la unidad bajo test. Podríamos incluso volver a lanzar el test ahora, lo cual seguramente provocará que el compilador o intérprete nos devuelva un mensaje de error distinto. Aquí ya dependemos un poco de circunstancias, como las convenciones del lenguaje en que estamos desarrollando, el IDE con el que trabajamos, etc.

En todo caso, se trata de ir dando pequeños pasos hasta que el compilador o intérprete quede conforme y pueda ejecutar el test. En principio, el test debería ejecutarse y fallar indicando que el resultado recibido de la unidad de software no coincide con el esperado.

En este punto hay que hacer una salvedad porque dependiendo del lenguaje, del framework y de algunas prácticas en testing, la forma concreta de este primer test puede ser un poco distinta. Por ejemplo, hay frameworks de test en los que basta con que la ejecución del test no arroje errores o excepciones para considerar que pasa, por lo que un test que simplemente instancia un objeto o invoca uno de sus métodos sería suficiente. En otros casos, es necesario que el test incluya una aserción y si no se hace ninguna considera que el test no pasa.

En cualquier caso, el objetivo de esta fase es lograr que el test se ejecute con éxito.

Con la kata Prime Factors estudiaremos el modo en que puede cambiar el código de producción para incorporar nueva funcionalidad.

Mejorar la estructura del código (y del test)

Cuando se ha logrado hacer pasar cada test debemos examinar el trabajo realizado hasta el momento y comprobar si es posible refactorizar tanto el código de producción como el de test. Aquí aplicamos los principios habituales: si detectamos cualquier smell, dificultad para entender lo que ocurre, duplicación de conocimiento, etc. debemos refactorizar el código para ponerlo en mejor estado antes de continuar.

En el fondo, las preguntas en este momento son:

• ¿Hay alguna manera mejor de organizar el código que he escrito?
• ¿Hay alguna manera mejor de expresar lo que este código hace y que sea más fácil de entender?
• ¿Puedo encontrar alguna regularidad y hacer que el algoritmo sea más general?

Para ello debemos mantener todos los tests que hayamos escrito pasando. Si alguno de los tests se pone en rojo tendríamos una regresión y habríamos estropeado, por así decir, la funcionalidad ya creada.

Tras el primer ciclo es normal no encontrar muchas oportunidades de refactor, pero no te fíes: siempre hay otra manera de ver y hacer las cosas. Por regla general, cuanto antes detectes oportunidades de reorganizar y limpiar el código y lo hagas, más fácil será el desarrollo.

Por ejemplo, nosotros hemos creado la función bajo test en el mismo archivo del test.

package roman

import "testing"

func TestRomanNumeralsConversion(t *testing.T) {
	roman := decToRoman(1)

	if roman != "I" {
		t.Errorf(
			"Decimal %d should convert to %s, but found %s", 
			1, 
			"I", 
			roman
		)
	}
}

func decToRoman(decimal int) string {
	return "I"
}

Resulta que hay una forma mejor de organizar ese código y es crear un archivo que contenga la función. De hecho, es una práctica recomendada en casi todos los lenguajes de programación. Sin embargo, al principio nos la podemos saltar.

//roman/roman.go

package roman

func decToRoman(decimal int) string {
	return "I"
}

Y, en el caso de Go, podemos convertirla en una función exportable si su nombre comienza con mayúsculas.

package roman

func DecToRoman(decimal int) string {
	return "I"
}

Para profundizar en todo lo que tiene que ver con el refactor al trabajar tendremos la kata Bowling Game.

Repetir el ciclo hasta terminar

Una vez que el código de producción hace pasar el test y está lo mejor organizado posible en esa fase, es el turno de escoger otro aspecto de la funcionalidad y crear un nuevo test que falle para describirlo.

Este nuevo test falla porque el código existente no cubre la funcionalidad deseada y es necesario introducir un cambio. Por tanto, nuestra misión ahora es poner este nuevo test en verde haciendo las transformaciones necesarias en el código, las cuales serán pequeñas si hemos sabido dimensionar correctamente nuestros tests anteriores.

Tras conseguir que el nuevo test pase, buscamos las oportunidades de refactor para tener un mejor diseño del código. A medida que avancemos en el desarrollo de la pieza de software veremos que los refactors posibles van siendo más significativos.

En los primeros ciclos comenzaremos con cambios de nombres, extracción de constantes y variables, etc. Luego pasaremos a introducir métodos privados o extraer ciertos aspectos a funciones. En algún momento descubriremos la necesidad de extraer funcionalidad a clases colaboradoras, etc.

Cuando estemos satisfechas con el estado del código repetimos el ciclo mientras nos queda funcionalidad por añadir.

¿Cuándo termina el desarrollo en TDD?

La respuesta obvia podría ser: cuando toda la funcionalidad está implementada.

Pero, ¿cómo sabemos esto?

Kent Beck proponía hacer una lista con todos los aspectos que habría que conseguir para considerar completa la funcionalidad. Cada vez que se consigue alguno se tacha de la lista. A veces, al progresar en el desarrollo nos damos cuenta de la necesidad de añadir, quitar, o mover, elementos en la lista. Es una buena recomendación.

Existe una manera más formal de asegurarnos de que una funcionalidad está completa. Básicamente, consiste en no ser capaz de crear un nuevo test que falle. En efecto, si un algoritmo está completamente implementado será imposible crear un test nuevo que pueda fallar.

Qué no es Test Driven Development

El resultado o outcome de Test Driven Development no es crear un software libre de defectos, aunque se previenen muchos de ellos; ni generar una suite de tests unitarios, aunque en la práctica se obtiene una con gran cobertura que puede llegar al 100%, con la contrapartida de que puede presentar redundancia. Pero nada de esto es el objetivo de TDD, en todo caso es un efecto colateral ciertamente beneficioso.

TDD no es Quality Assurance

Aunque usamos las mismas herramientas (tests), las usamos para finalidades distintas. Los tests en TDD guían el desarrollo, estableciendo objetivos específicos para alcanzar añadiendo código o aplicando cambios en él. El resultado de TDD es una suite de tests que puede utilizarse en QA como tests de regresión, aunque es frecuente que tengamos que retocar esos tests de una manera u otra. En unos casos para eliminar tests redundantes y en otros para asegurar que las casuísticas están bien cubiertas.

En cualquier caso, TDD ayuda enormemente el proceso de QA porque previene muchos de los defectos más comunes y contribuye a construir un código bien estructurado y con bajo acoplamiento, aspectos que incrementan la fiabilidad del software, nuestra capacidad para intervenir en caso de errores e incluso la posibilidad de crear nuevos tests en un future.

TDD no reemplaza el diseño

TDD es una herramienta para contribuir al diseño de software, pero no lo reemplaza.

Cuando desarrollamos unidades pequeñas y con una funcionalidad muy bien definida, TDD nos ayuda a establecer el diseño del algoritmo gracias a la red de seguridad proporcionada por los tests que vamos creando.

Pero cuando la unidad considerada es mayor, un análisis previo que nos lleve a un “boceto” de los elementos principales de la solución nos permite tener un marco de desarrollo.

El enfoque outside-in intenta integrar el proceso de diseño en el desarrollo, usando lo que Sandro Mancuso etiqueta como Just-in-time design: partimos de una idea general de cómo se estructura y de cómo funcionará el sistema y diseñamos en el ámbito de la iteración en la que nos encontremos.

En qué nos ayuda TDD

Lo que TDD nos proporciona es una herramienta que:

• Guía el desarrollo del software de una forma sistemática y progresiva.
• Nos permite realizar afirmaciones contrastables sobre si la funcionalidad requerida ha sido implementada o no.
• Nos ayuda a evitar la necesidad de diseñar todos los detalles de implementación anticipadamente, ya que en sí misma es una herramienta de ayuda al diseño de los componentes del software.
• Nos permite posponer decisiones a varios niveles.
• Nos permite centrarnos en problemas muy concretos, avanzando en pasos pequeños y fáciles de revertir si introducimos errores.

Beneficios

Varios estudios han mostrado evidencias que apuntan a favor de que la aplicación de TDD tiene beneficios en los equipos de desarrollo. No son evidencias concluyentes, pero las investigaciones realizadas tienden a coincidir en que con TDD:

• Se escribe una mayor cantidad de tests
• El software tiene menos defectos
• La productividad no se ve disminuida, incluso puede aumentar

Es bastante difícil cuantificar el beneficio de usar TDD en cuanto a productividad o velocidad, sin embargo, subjetivamente se pueden experimentar varios beneficios.

Uno de ellos es que la metodología TDD puede bajar la carga cognitiva del desarrollo. Esto es así porque favorece dividir el problema en tareas pequeñas con un foco muy definido, lo que nos permite ahorrar la limitada capacidad de nuestra memoria de trabajo.

La evidencia anecdótica apunta a que las desarrolladoras y equipos que introducen TDD reducen los defectos, reducen el tiempo dedicado a bugs, aumentan la confianza a la hora de desplegar y la productividad no se ve afectada negativamente.

Referencias

• Test Driven Development¹
• Why Test-driven Development²
• Test driven development: empirical body of evidence³
• Does Test-Driven Development Really Improve Software Design Quality⁴
• 6 Misconceptions about TDD – Part 1. TDD Brings Little Business Value and Isn’t Worth it⁵
• TDD is about design, not testing⁶
• Does TDD really lead to good design?⁷
• Using TDD to influence design⁸

2 Conceptos básicos

A continuación definiremos algunos conceptos que se usan a lo largo del libro. Hay que entenderlos en el contexto de Test Driven Development.

Test

Un test es una pequeña pieza de software, normalmente una función, que ejecuta otra pieza de software y verifica si produce un resultado o efecto que esperamos. Un test es básicamente un ejemplo de uso de la unidad bajo test en el que se define un escenario y se ejecuta la unidad probada para ver si el resultado es que el que hemos previsto.

Muchos lenguajes utilizan la noción de TestCase, una clase que agrupa un cierto número de tests relacionados entre sí. En ese caso, cada método es un test, aunque es frecuente llamar test al test case.

Test como especificación

Un test como especificación utiliza ejemplos de uso de la pieza de software probada para describir cómo debería funcionar. Se utilizan, sobre todo, ejemplos que sean significativos, pero no siempre se hace de manera formal.

Se opone al test como verificación, propio de la QA, en el que se prueba la pieza de software eligiendo los casos de prueba de manera sistemática para verificar que cumple lo que se espera de ella.

Test que falla

Un test que falla es una especificación que no se cumple todavía porque no se ha añadido el software de producción que permite hacerlo pasar. Típicamente, los frameworks de testing lo representan en color rojo.

Test que pasa

Un test que pasa es una especificación que ejecuta un código de producción que genera el efecto o respuesta esperado. Los frameworks de testing los suelen representar en color verde.

Tipos de tests

Unitarios

Son tests que prueban una unidad de software en aislamiento, sus dependencias se doblan para mantener controlada su influencia en el resultado.

De integración

Los tests de integración habitualmente pruebas conjuntos de unidades de software, de modo que podemos verificar su comunicación y su acción combinada.

De aceptación

Los tests de aceptación son tests de integración que prueban un sistema de software como un consumidor más del mismo. Normalmente, los escribimos en función de los intereses del negocio.

Test Case

Es una clase que agrupa varios tests.

Test Suite

Es un conjunto de test y/o test cases, que habitualmente se pueden ejecutar juntos.

Código de producción

En TDD nos referimos con el nombre de código de producción al código que escribimos para pasar los tests y que, eventualmente, acabará siendo ejecutado en un sistema en producción.

Unidad de software

Unidad de software es un concepto bastante flexible y que hay que interpretar en un contexto, pero se refiere normalmente a una pieza de software que se puede ejecutar de forma unitaria y aislada, incluso aunque esté compuesta de varios elementos.

Subject under test

La unidad de software que es ejercitada en un test. Existe una discusión sobre cuál es el alcance de una unidad. En un extremo se encuentran quienes consideran que una unidad es una función, un método o incluso una clase. Sin embargo, también podemos considerar como unidad bajo test un conjunto de funciones o clases que son testeadas a través de la interfaz pública de una de ellas.

Refactor

Refactor es un cambio en el código que no altera su comportamiento ni su interfaz. La mejor manera de asegurar esto es que exista al menos un test que ejercita el fragmento de código que se está modificando, de modo que tras cada cambio nos aseguremos de que el test sigue pasando, lo que demostraría que no ha cambiado el comportamiento aunque se haya modificado la implementación.

Algunas técnicas o patrones de refactor están descritos en recopilaciones como esta de Refactoring Guru o el libro clásico de Martin Fowler

Refactor automático

Precisamente porque algunos refactors están muy bien identificados y caracterizados ha sido posible desarrollar herramientas capaces de ejecutarlos automáticamente. Estas herramientas están disponibles en los IDE.

3 Coding-dojo y katas

Kata

En el mundo del software llamamos katas a ejercicios de diseño y programación que plantean problemas relativamente sencillos y acotados con los que practicar metodologías de desarrollo.

El término es un prestamo de la palabra japonesa que designa los ejercicios de entrenamiento característicos de las artes marciales. Se atribuye su introducción a Dave Thomas (The Pragmatic Programmer)¹, refiriéndose a la realización de pequeños ejercicios de código, repetidos una y otra vez hasta alcanzar un alto grado de fluidez o automatización.

Aplicado a TDD, las katas persiguen entrenar los ciclos de test-producción-refactor y la capacidad de añadir comportamiento mediante pequeños incrementos de código. Estos ejercicios te ayudarán a dividir una funcionalidad en partes pequeñas, a escoger ejemplos, a proceder paso a paso en el proyecto, a cambiar prioridades según la información que nos proporcionan los tests, etc.

La idea es repetir una misma kata muchas veces. Además de adquirir soltura con el proceso, en cada una de las repeticiones existe la posibilidad de descubrir nuevas estrategias. Con la práctica repetida, podremos favorecer el desarrollo de ciertos hábitos y el reconocimiento de patrones, automatizando hasta cierto punto nuestro proceso de desarrollo.

Puedes ejercitarte con katas de forma individual o con otras personas. Una forma sistemática de hacerlo es mediante un Coding Dojo.

Coding-dojo

Un coding dojo es un taller en el que un grupo de personas, con independencia de su nivel de conocimiento, realiza una kata de forma colaborativa y no competitiva.

La idea de Coding Dojo o Coder’s Dojo fue presentada en la conferencia XP2005 por Laurent Bossavit y Emmanuel Gaillot.

La estructura básica de un coding-dojo es bastante sencilla:

• Presentación del problema, organización del ejercicio (5-10 min)
• Sesión de código (30-40 min)
• Puesta en común sobre el estado del ejercicio (5-10 min)
• Continua la sesión de código (30-40 min)
• Puesta en común de las soluciones alcanzadas

La sesión de código puede desarrollarse de varias formas:

• Prepared kata. Un presentador explica cómo resolver el ejercicio, pero contando con el feedback de las personas presentes. No se avanza hasta que se consigue un consenso. Es una forma muy adecuada de trabajar cuando el grupo se está iniciando y pocas personas están acostumbradas a la metodología.
• Randori kata. La kata se realiza en pairing usando algún sistema para alternar entre la conductora (al teclado) y la copiloto. Las demás presentes colaboran haciendo sugerencias.
• Hands-on workshop. Una alternativa es que las participantes formen parejas y trabajen colaborativamente en la kata. A mitad del ejercicio se hace una parada para comentar sobre lo realizado unos minutos. Al final de la sesión se presentan las distintas soluciones en el punto donde hayan llegado. Cada pareja puede elegir el lenguaje de programación preferido, por lo que es una gran oportunidad para quienes quieran iniciarse en uno nuevo. También puede ser una buena forma para quienes se inician si se forman parejas con distinto nivel de experiencia.

Consejos para realizar las katas individualmente

Al principio puede ser buena idea asistir a katas dirigidas. Básicamente, se trata de una kata que hace una persona experta en forma de live coding mientras explica o comenta con la audiencia los distintos pasos, de modo que puedes ver la dinámica en acción. Si no tienes esta posibilidad, que puede ser lo más habitual, es buena idea ver alguna kata en vídeo. En los capítulos dedicados a cada kata puedes encontrar algunos enlaces.

Ante todo, el objetivo de las katas es ejercitar la disciplina TDD, la aplicación de las tres leyes y el ciclo red-green-refactor. El código de producción es lo de menos en el sentido de que no es el objeto del aprendizaje, aunque siempre será correcto si los tests pasan. Sin embargo, cada ejecución de la kata nos puede llevar a descubrir detalles nuevos y formas diferentes de afrontar cada fase.

Es decir, las katas están diseñadas para aprender a desarrollar software usando los tests como guía y para entrenar el mindset y los procesos de razonamiento y análisis que nos ayudan en esa tarea. Por lo general, desarrollar una buena metodología TDD nos ayudará a escribir mejor software gracias a las restricciones que nos impone.

Obviamente, los primeros intentos te llevarán su tiempo, te meterás en caminos aparentemente sin retorno o te saltarás los pasos del ciclo. Cuando ocurre eso, no tienes más que retroceder o volver a empezar de cero. Se trata de ejercicios que no tienen una respuesta correcta única.

De hecho, cada lenguaje de programación, enfoque o librería de test podrían favorecer unas soluciones u otras. Puedes hacer una kata varias veces intentando asumir diferentes supuestos de partida en cada intento o aplicando distintos paradigmas o condiciones.

Si encuentras puntos en los que puedes elegir diversos cursos de acción, toma nota de ellos para repetir el ejercicio y probar más adelante otro camino a ver a dónde te dirige.

En TDD es muy importante centrarse en el aquí y el ahora que nos define cada test que no pasa y no agobiarse por alcanzar el objetivo final. Esto no quiere decir dejarlo de lado o dedicarnos a otra cosa. Simplemente, quiere decir que hay que recorrer ese camino paso a paso, y hacerlo así nos llevará a la meta casi sin darnos cuenta, con mucho menos esfuerzo y más solidez. Adquirir esta mentalidad, ocuparse solo del problema que tengo delante, nos ayudará a reducir el estrés y pensar con más claridad.

Si es posible prueba a hacer la misma kata en diferentes lenguajes, incluso en diferentes frameworks de testing. Las dos familias más conocidas son:

• xSpec, que están orientados a TDD y tienden a favorecer el testing mediante ejemplos, proporcionando sintaxis y utilidades específicas. Su hándicap es que no suelen funcionar bien para QA.
• xUnit, que son los frameworks de testing más genéricos, aunque más orientados a QA. Sin embargo, puedes usarse para TDD perfectamente.

Cómo introducir TDD en equipos de desarrollo

Introducir la metodología TDD en equipos de desarrollo es un proceso complejo. Ante todo, es importante contribuir a generar una cultura abierta a la innovación, a la calidad y al aprendizaje. Las mayores reticencias suelen venir del miedo a que el uso de TDD ralentice el desarrollo, o que al principio no se vea una aplicación directa en los problemas diarios.

Personalmente, creo que puede ser interesante utilizar canales formales e informales. He aquí algunas ideas.

• Establecer un tiempo semanal, unas dos horas, para un coding-dojo abierto a todo el equipo. Dependiendo del nivel de experiencia puede empezarse con katas dirigidas, o sesiones tipo hands-on, o el formato que nos parezca más adecuado. Lo ideal es que diversas personas lo puedan dinamizar.
• Introducir en los equipos personas con experiencia que puedan ayudar a introducir TDD en sesiones de trabajo en pairing o mob-programming, guiando a otras compañeras.
• Organizar formación específica, con ayuda externa si no se cuenta con personas con suficiente experiencia.
• Introducir, si no se tiene, un blog técnico en el que se publiquen artículos, ejercicios y ejemplos sobre el tema.

Repositorios de katas

• Katalyst²
• Kata-log³
• Coding dojo⁴
• Codekata⁵
• Agile kata⁶

Referencias

• The Programming Dojo⁷
• What is coding dojo⁸
• The Coder’s Dojo – A Different Way to Teach and Learn Programming - Abstract⁹

TDD clásica

En esta parte presentamos una serie de ejercicios de código en los que exploraremos en profundidad cómo se hace Test Driven Development.

Usaremos el estilo o aproximación clásica de la disciplina. TDD es una metodología de desarrollo de software redescubierta por Kent Beck, basándose en el modo en que se construían los primeros programas de ordenador. Entonces, se realizaban primero los cálculos a mano para tener la referencia del resultado esperado y que debía reproducirse con el ordenador. En TDD, se escribe un programa muy sencillo que comprueba que el resultado de otro programa es el que se espera. La clave está en que ese programa aún no está escrito. Es así de simple.

La metodología fue presentada por Beck en su libro TDD by example, en el cual, entre otras cosas, se enseña a construir un framework de testing mediante TDD. Posteriormente, diversos autores han contribuido a refinar y sistematizar el modelo.

4 Las leyes de TDD

Desde la introducción de la metodología TDD por Kent Beck se ha intentado definir un framework sencillo que proporcione una guía para aplicarla en la práctica.

Inicialmente, Kent Beck propuso dos reglas muy básicas:

• No escribir una línea de código sin antes tener un test automático que falle.
• Eliminar la duplicación.

Es decir, para poder escribir código de producción, primero debemos tener un test que no pase y que requiera que escribamos ese código, precisamente porque eso es lo necesario para que el test pase.

Una vez que lo hemos escrito y viendo que el test pasa, nuestro esfuerzo se centra en revisar el código escrito y eliminar en lo posible la duplicación. Esto es muy genérico, porque, por una parte, se refiere al refactoring y, por otra parte, al acoplamiento entre el test y el código de producción. Y al ser tan genérico resulta difícil bajarlo en acciones prácticas.

Además, estas reglas no nos dicen nada acerca de cuan grandes son los saltos de código implicados en cada ciclo. Beck sugiere en su libro que los pasos o baby steps pueden ser tan pequeños o tan grandes como nos resulten útiles. En general, recomienda usar pasos pequeños cuando tenemos inseguridad o poco conocimiento del algoritmo, mientras que permite pasos más grandes si por experiencia y conocimientos tenemos claro qué hacer a continuación.

Con el tiempo, y a partir de la metodología aprendida del propio Beck, Robert C. Martin estableció las “tres leyes”, que no solo definen el ciclo de acciones en TDD, sino que también proporcionan criterios sobre cómo de grandes deberían ser los pasos en cada ciclo:

• No se permite escribir ningún código de producción a menos que haga pasar un test unitario que falle
• No se permite escribir más de un test unitario que sea suficiente para fallar; y los errores de compilación son fallos.
• No se permite escribir más código de producción del que sea necesario para hacer pasar un test unitario que falle

Las tres leyes son lo que hace diferente TDD de simplemente escribir tests antes que el código.

Estas leyes imponen una serie de restricciones cuyo objetivo es forzarnos a seguir un determinado orden y ritmo de trabajo. Definen una serie de condiciones que, si se cumplen, generan un ciclo y guían nuestra toma de decisiones. Entender cómo funcionan, nos ayudará a aprovechar al máximo la capacidad de TDD para ayudarnos a generar código de calidad y que podamos mantener.

Estas leyes se tienen que cumplir todas a la vez porque funcionan juntas.

Las leyes en detalle

No se permite escribir ningún código de producción a menos que haga pasar un test unitario que falle

La primera ley nos dice que no podemos escribir código de producción si no hace pasar un test unitario existente que actualmente está fallando. Esto implica lo siguiente:

• Tiene que existir un test que describa un aspecto nuevo del comportamiento de la unidad que estamos desarrollando.
• Este test tiene que fallar porque en el código de producción no existe nada que lo haga pasar.

En resumen, la primera ley nos fuerza a escribir un test que defina el comportamiento que vamos a implementar en la unidad de software que estamos desarrollando antes de plantearnos cómo hacerlo.

Ahora bien, ¿cómo tiene que ser el test que escribamos?

No se permite escribir más de un test unitario que sea suficiente para fallar; y los errores de compilación son fallos.

La segunda ley nos dice que el test debe ser suficiente para fallar y que tenemos que considerar fallos los errores de compilación o su equivalente en lenguajes interpretados. Por ejemplo, entre estos errores estarían algunos tan obvios como que la clase o función no existe o no ha sido definida.

Debemos evitar la tentación de escribir un esqueleto de la clase o la función antes de escribir el primer test. Recuerda que estamos hablando de Test Driven Development. Por tanto, son los tests los que nos dicen qué código de producción escribir y cuándo y no al revés.

Que el test sea suficiente para fallar quiere decir que el test ha de ser muy pequeño en diversos sentidos y es algo que al principio resulta bastante difícil de definir. Con frecuencia se habla del test “más sencillo”, del caso más simple, pero no es exactamente así.

¿Qué condiciones tendría que reunir un test en TDD, particularmente el primero?

Pues básicamente forzarnos a escribir el mínimo código posible que se pueda ejecutar. Lo mínimo en OOP sería instanciar la clase que queremos desarrollar sin preocuparnos de más detalles, de momento. El test concreto variará un poco en función del lenguaje y framework de testing que estemos utilizando.

Veamos este ejemplo. Se trata de la kata Leap Year en la se busca crear una función para averiguar si un año dado es bisiesto (leap year) o no. Para el ejemplo, mi intención es crear un objeto Year, al que le pueda preguntar si es bisiesto enviándole el mensaje isLeap. He encontrado este ejercicio en varias recopilaciones de katas sin mención de autoría. Para este capítulo, los ejemplos están escritos en C#.

Las reglas son:

• Los años no divisibles por 4 no son bisiestos (como 1997).
• Los años divisibles por 4 son bisiestos (como 1996), excepto:
• Si son divisibles por 100 no son bisiestos (como 1900).
• Si son divisibles por 400 serán bisiestos (como 2000).

Nuestro objetivo sería poder usar objetos Year de esta forma:

var year = new Year(1996);

if (year.IsLeap()) {
	// do something
}

La tentación habitual es tratar de empezar de la siguiente forma porque parece que es el ejemplo del caso más sencillo posible.

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void ShouldNotBeLeapYear()
        {
            var year = new Year(1997);
            Assert.False(year.IsLeap())
        }
    }
}

Sin embargo, no es el test más sencillo que pueda fallar por una única razón. En realidad puede fallar por cinco razones, al menos:

• La clase Year no existe todavía.
• Tampoco aceptaría parámetros pasados por la constructora.
• No responde al mensaje IsLeap
• Podría no retornar nada.
• Podría devolver una respuesta incorrecta.

Es decir, podemos esperar que el test falle por estas cinco causas y solo la última es la que el test realmente describe. Tenemos que reducirlas a solo una.

En este caso, es muy fácil ver que hay una dependencia entre los diversos motivos de fallo, de tal manera que para que se pueda producir uno, tiene que haberse solucionado el anterior. Evidentemente, es necesario que exista una clase que poder instanciar. Por tanto, nuestro primer test debería ser mucho más modesto y esperar únicamente que la clase se pueda instanciar:

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanInstantiate()
        {
            new Year();
        }
    }
}

Si lanzásemos este test veríamos que falla por razones obvias: no existe la clase que se pretende instanciar en ninguna parte. El test está fallando por un problema de compilación o equivalente. Por tanto, podría ser un test suficiente para fallar.

A lo largo del proceso veremos que este test es redundante y que podemos prescindir de él, pero no nos adelantemos. Todavía tenemos que conseguir que pase.

No se permite escribir más código de producción del que sea necesario para hacer pasar un test unitario que falle

La primera y la segunda leyes nos dicen que tenemos que escribir un test y cómo debería ser ese test. La tercera ley nos dice cómo tiene que ser el código de producción. Y la condición que nos pone es que haga pasar el test que hemos escrito.

Es muy importante entender que es el test el que nos dice qué código necesitamos implementar y, por tanto, aunque tengamos la certeza de que va a fallar porque ni siquiera tenemos un archivo con el código necesario para definir la clase, debemos ejecutar el test y esperar su mensaje de error.

Es decir: tenemos que ver que el test, efectivamente, falla.

Lo primero que nos dirá al tratar de ejecutarlo es que la clase no existe. En TDD eso no es un problema, sino una indicación de lo que debemos hacer: añadir un archivo con la definición de la clase. Seguramente con las herramientas del IDE podamos generar ese código de manera automática, y es aconsejable hacerlo así.

En nuestro ejemplo, el mensaje del test dice:

The type or namespace name 'Year' could not be found 
(are you missing a using directive or an assembly reference?)

Y simplemente tendremos que crear la clase Year.

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanInstantiate()
        {
            new Year();
        }
    }

    public class Year
    {
    }
}

En este punto volvemos a ejecutar el test para comprobar si pasa de rojo a verde. En muchos lenguajes este código será suficiente. En algunos casos puedes necesitar algo más.

Si es así, y el test pasa, el primer ciclo está completo y podremos pasar al siguiente comportamiento, a no ser que consideremos que tenemos posibilidades de hacer un refactor del código existente. Por ejemplo, lo habitual aquí sería mover la clase Year a su propio archivo.

namespace LeapYear
{
    public class Year
    {
    }
}

Si el test no ha pasado, nos fijaremos en el mensaje mostrado por el test fallido y actuaremos en consecuencia, añadiendo el código mínimo necesario para que, finalmente, pase y se ponga en verde.

El segundo test y las tres leyes

Cuando hemos logrado hacer pasar el primer test aplicando las tres leyes podríamos pensar que no hemos conseguido realmente nada. Ni siquiera hemos abordado los posibles parámetros que podría necesitar la clase para ser construida, ya sean datos o colaboradores en el caso de servicios o use cases. Incluso el IDE se estará quejando de que no estamos asignando el objeto instanciado a ninguna variable.

Sin embargo, es importante ceñirse a la metodología, sobre todo en estas primeras fases. Con la práctica y la ayuda de un buen IDE el primer ciclo nos habrá llevado apenas unos pocos segundos. En esos pocos segundos hemos escrito un código, ciertamente muy pequeño, pero totalmente respaldado por un test.

Nuestro objetivo sigue siendo que los tests nos dicten qué código tenemos que escribir para implementar cada nuevo comportamiento. Como nuestro primer test ya pasa, tendríamos que escribir el segundo.

Aplicando las tres leyes, lo que viene a continuación es:

• Escribir un nuevo test que defina un comportamiento
• Que ese test sea el mínimo posible para obligarnos a hacer un cambio en el código de producción
• Escribir el código de producción mínimo y suficiente que hace pasar el test

¿Cuál podría ser el próximo comportamiento que necesitamos definir? Si en el primer test nos hemos forzado a escribir el código mínimo necesario para instanciar la clase, el segundo test puede llevarnos por dos caminos:

• Forzarnos a escribir el código necesario para validar parámetros del constructor y, por tanto, poder instanciar un objeto con todo lo necesario.
• Forzarnos a introducir el método que ejecuta el comportamiento deseado.

Así, en nuestro ejemplo, podríamos simplemente asegurarnos de que Year es capaz de responder al mensaje IsLeap.

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanInstantiate()
        {
            new Year();
        }        
        
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year();
            year.IsLeap();
        }
    }
}

El test arrojará este mensaje de error:

'Year' does not contain a definition for 'IsLeap' and no accessible extension...

Que nos indica que el siguiente paso debería ser introducir el método que responde a ese mensaje:

namespace LeapYear
{
    public class Year
    {
        public void IsLeap()
        {
        }
    }
}

El test pasa, indicando que ahora los objetos de tipo Year, pueden atender al mensaje IsLeap.

Habiendo llegado a este punto, nos podríamos preguntar: ¿qué pasa si no cumplimos las tres leyes de TDD?

Violaciones de las tres leyes y sus consecuencias

Obviando la broma fácil de que no acabaremos en la cárcel o con una multa por incumplir las leyes de TDD, lo cierto es que sí tendríamos que apechugar con algunas consecuencias.

Primera ley: escribir código de producción sin tener un test

La consecuencia más inmediata es que rompemos el ciclo red-green. El código que escribimos ya no está guiado ni cubierto por tests. De hecho, si queremos tener esa parte testeada, tendremos que hacer un test a posteriori (un test de QA).

Imagina que hacemos esto:

using System;

namespace LeapYear
{
    public class Year
    {
        private readonly int _aYear;

        public Year(int aYear)
        {
            _aYear = aYear;
        }

        public bool? IsLeap()
        {
            if (_aYear % 4 == 0)
            {
                return true;
            }
            
            return false;
        }
    }
}

Los tests existentes fallarán porque hay que pasar un parámetro a la constructora, además no tenemos ningún test que se haga cargo de verificar el comportamiento que hemos introducido. Tendríamos que añadir tests para cubrir la funcionalidad que hemos incorporado, pero ya no estamos dirigiendo el desarrollo.

Segunda ley: escribir más que un test que falle

Esto podemos interpretarlo de dos formas: escribir varios tests o escribir un test que supone un salto de comportamiento demasiado grande.

Escribir más de un test provocaría varios problemas. Para hacerlos pasar todos necesitaríamos implementar una gran cantidad de código y la guía que nos podrían proporcionar esos mismos tests se desdibuja tanto que es como no tenerla. No contaríamos con una indicación concreta que podamos resolver implementando nuevo código.

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanInstantiate()
        {
            new Year();
        }        
        
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year();
            year.IsLeap();
        }

        [Test]
        public void CommonYearsShouldNotBeLeap()
        {
            var year = new Year(1997);
            Assert.False(year.IsLeap());
        }
        
        [Test]
        public void YearDivisibleBy4ShouldBeLeap()
        {
            var year = new Year(1996);
            Assert.True(year.IsLeap());
        }
    }
}

Aquí hemos añadido dos tests. Para hacerlos pasar tendríamos que definir dos comportamientos. Además, son tests demasiado grandes. Todavía no hemos establecido, por ejemplo, que se pasa un parámetro a la constructora, ni que la respuesta será del tipo bool. Estos tests mezclan diversas responsabilidades y tratan de probar demasiadas cosas a la vez. Tendríamos que escribir demasiado código de producción de una sola vez, con lo que conlleva de inseguridad y espacio para que se produzcan errores.

En lugar de eso, necesitamos hacer tests para incrementos de funcionalidad más pequeños. Podemos ver varias posibilidades:

Para introducir que la respuesta es bool podemos asumir que, por defecto, los años no son bisiestos, por lo que esperaremos una respuesta false:

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanInstantiate()
        {
            new Year();
        }        
        
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year();
            year.IsLeap();
        }

        [Test]
        public void ByDefaultYearsAreNotLeapYears()
        {
            var year = new Year();
            Assert.False(year.IsLeap());
        }
    }
}

El error es:

Argument 1: cannot convert from 'void' to 'bool?'

Se puede resolver con:

using System;

namespace LeapYear
{
    public class Year
    {
        public Year()
        {

        }

        public bool IsLeap()
        {
            return false;
        }
    }
}

Sin embargo, tenemos otra forma de hacerlo. Puesto que el lenguaje tiene tipado fuerte, podemos usar el sistema de tipos como test. Así en lugar de crear un test nuevo:

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanInstantiate()
        {
            new Year();
        }        
        
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year();
            year.IsLeap();
        }
    }
}

Cambiamos el tipo de retorno de IsLeap:

using System;

namespace LeapYear
{
    public class Year
    {
        public Year()
        {

        }

        public bool IsLeap()
        {
            
        }
    }
}

Al ejecutar el test nos indicará que hay un problema, pues no devolvemos nada en la función:

'Year.IsLeap()': not all code paths return a value

Y finalmente, no tenemos más que añadir una respuesta por defecto, que será false:

using System;

namespace LeapYear
{
    public class Year
    {
        public Year()
        {

        }

        public bool IsLeap()
        {
            return false;
        }
    }
}

Para introducir el parámetro de construcción podríamos recurrir a un refactor. Pero para esto el lenguaje de programación nos puede condicionar, llevándonos a distintas soluciones.

La vía del refactor es sencilla. Tan solo tenemos que incorporar el parámetro, aunque de momento no lo usaremos. En C# y otros lenguajes podemos hacerlo por la vía de introducir un constructor alternativo, de este modo los tests seguirán pasando. En otros lenguajes, podríamos marcar el parámetro como opcional.

using System;

namespace LeapYear
{
    public class Year
    {
        private readonly int _aYear;

        public Year()
        {
            
        }

        public Year(int aYear)
        {
            _aYear = aYear;
        }
        
        public bool IsLeap()
        {
            return false;
        }
    }
}

Como para nosotras no tiene sentido un constructor sin parámetros, ahora podríamos eliminarlo, pero antes tendríamos que refactorizar los tests, de modo que usemos la versión con parámetro:

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanInstantiate()
        {
            new Year(1997);
        }        
        
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year(1997);
            year.IsLeap();
        }
    }
}

Lo cierto es que el primer test nos sobra, porque está implícito en el otro.

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year(1997);
            year.IsLeap();
        }

    }
}

Y ahora podemos eliminar el constructor sin parámetros, ya que no se volverá a usar en ningún caso:

using System;

namespace LeapYear
{
    public class Year
    {
        private readonly int _aYear;

        public Year(int aYear)
        {
            _aYear = aYear;
        }
        
        public bool IsLeap()
        {
            return false;
        }
    }
}

Tercera ley: escribir más del código de producción necesario para que pase el test

Se trata quizá de la violación más frecuente de todas. Llega un momento en que “vemos” el algoritmo con tanta claridad que nuestro impulso es escribirlo ya y terminar el proceso. Sin embargo, esto nos puede llevar a obviar algunas situaciones. Por ejemplo, en una aplicación podríamos “ver” el algoritmo general e implementarlo. Sin embargo, eso podría habernos distraído de uno o varios casos particulares y no contemplarlos, lo que una vez incorporado a la aplicación y desplegado posiblemente aparecerían errores en producción, incluso con pérdidas económicas.

Por ejemplo, si añadimos un test para probar que controlamos los años no bisiestos:

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year(1997);
            year.IsLeap();
        }

        [Test]
        public void CommonYearsAreNoLeapYears()
        {
            var year = new Year(1997);
            Assert.False(year.IsLeap());
        }
    }
}

En el estado actual de nuestro ejercicio, un exceso de código sería este:

using System;

namespace LeapYear
{
    public class Year
    {
        private readonly int _aYear;

        public Year(int aYear)
        {
            _aYear = aYear;
        }
        
        public bool IsLeap()
        {
            if (_aYear % 4 == 0)
            {
                if (_aYear % 400 == 0)
                {
                    return false;
                }

                if (_aYear % 100 == 0)
                {
                    return true;
                }

                return true;
            }
            return false;
        }
    }
}

El test pasa con este código, pero como puedes ver se ha introducido mucho más del necesario para tener el comportamiento definido por el test, añadiendo código para controlar los años bisiestos y los casos especiales. Así que aparentemente todo está bien.

Si probamos un año bisiesto, veremos que el código funciona, lo que refuerza nuestra impresión de que todo es correcto.

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year(1997);
            year.IsLeap();
        }

        [Test]
        public void CommonYearsAreNoLeapYears()
        {
            var year = new Year(1997);
            Assert.False(year.IsLeap());
        }

        [Test]
        public void ShouldIdentifyStandardLeapYears()
        {
            var year = new Year(1996);
            Assert.True(year.IsLeap());
        }
    }
}

Pero, un nuevo test falla. Los años divisibles por 100 no deben ser bisiestos (salvo que sean divisibles por 400), y este error lleva un buen rato en nuestro código, pero hasta ahora no teníamos un test que ejecutase esa parte del código.

using System;
using System.Runtime.Remoting.Metadata.W3cXsd2001;
using NUnit.Framework;

namespace LeapYear
{
    public class Tests
    {
        [Test]
        public void CanRespondToIsLeapMessage()
        {
            var year = new Year(1997);
            year.IsLeap();
        }

        [Test]
        public void CommonYearsAreNoLeapYears()
        {
            var year = new Year(1997);
            Assert.False(year.IsLeap());
        }

        [Test]
        public void ShouldIdentifyStandardLeapYears()
        {
            var year = new Year(1996);
            Assert.True(year.IsLeap());
        }
        
        [Test]
        public void ShouldIdentifyCenturyExceptionOfLeapYears()
        {
            var year = new Year(1900);
            Assert.False(year.IsLeap());
        }
    }
}

Este es el tipo de problemas que pueden pasar desapercibidos cuando añadimos demasiado código para hacer pasar un test. El exceso de código posiblemente no afecta al test que tenemos entre manos, por lo que no sabremos si esconde algún tipo de problema y no lo sabremos si no llegamos a construir un test que lo ponga de manifiesto. O peor: no lo sabremos hasta que el bug explota en producción.

La solución es bastante simple: añade solo el código estrictamente necesario para que el test pase, aunque solo sea devolver el valor esperado por el propio test. No introduzcas comportamiento si no existe antes un test que te obligue a ello porque está fallando.

En nuestro caso era el test que verificaba el tratamiento de los años no bisiestos. De hecho, el siguiente test, que pretendía introducir el comportamiento de detectar los años bisiestos estándar (años divisibles por 4) pasaba sin necesidad de añadir nuevo código. Esto nos lleva al siguiente punto.

Qué significa que un test pase nada más escribirlo

Cuando escribimos un test y pasa sin añadir código de producción puede ser por alguno de estos motivos:

• El algoritmo que hemos escrito es lo bastante general como para cubrir todos los casos posibles: hemos terminado nuestro desarrollo.
• El ejemplo que hemos elegido no es cualitativamente diferente de otros que ya hemos usado y, por lo tanto, no nos fuerza a escribir código de producción. tenemos que encontrar otro ejemplo.
• Hemos añadido demasiado código, que es lo que acabamos de contar en el apartado anterior.

En esta kata Leap Year, por ejemplo, llegará un momento en que no hay forma de escribir un test que falle porque el algoritmo cubre todos los casos: años no bisiestos, bisiestos, años no bisiestos cada 100 años y bisiestos cada 400 años.

La otra posibilidad es que el ejemplo escogido no sea representativo de un nuevo comportamiento, lo que puede venir dado por una mala definición de la tarea o por no haber analizado bien los posibles escenarios.

El ciclo red-green-refactor

Las tres leyes establecen un framework que podríamos llamar “de bajo nivel”. Martin Fowler, por su parte, define el ciclo TDD en estas tres fases que estarían en un nivel superior de abstracción:

• Escribe un test para el siguiente fragmento de funcionalidad que deseas añadir.
• Escribe el código de producción necesario para que el test pase.
• Refactoriza el código, tanto el nuevo como el anterior, para que esté bien estructurado.

Estas tres fases definen lo que se suele conocer como el ciclo “red-green-refactor”, nombrado así por el estado de los tests en cada una de las fases del ciclo:

• Red: la creación de un test que falla (está en rojo) y que describe la funcionalidad o comportamiento que queremos introducir en el software de producción.
• Green: la escritura del código de producción necesario para hacer pasar el test (ponerlo en verde) con lo cual se verifica que se ha añadido el comportamiento especificado.
• Refactor: manteniendo los tests en verde, reorganizar el código para estructurarlo mejor, haciéndolo más legible y sostenible sin perder la funcionalidad desarrollada hasta el momento.

En la práctica los ciclos de refactor surgen después de un cierto número de ciclos de las tres leyes. Los pequeños cambios impulsados por estas se acumulan hasta llegar a un punto en el que comienzan a aparecer smells de código que requieren el refactor.

Referencias

• The three rules of TDD¹
• The three rules of TDD - video²
• Refactoring the three laws of TDD³
• TDD with PHPSpec⁴
• The 3 Laws of TDD: Focus on One Thing at a Time⁵
• Test Driven Development⁶
• The cycles of TDD⁷

5 Fizz Buzz

Entendiendo las leyes y ciclos de TDD

La kata FizzBuzz es una de las katas más sencillas para empezar a practicar TDD. Plantea un problema muy simple y bien acotado, por lo que en una primera fase es muy fácil resolverla por completo en una sesión de una o dos horas. Pero también se pueden ampliar sus requerimientos y lograr desarrollos más complejos, como poner el requisito de que las reglas o el tamaño de la lista sean configurables, que se puedan añadir nuevas reglas, etc.

En este caso, al tratarse de nuestra primera kata, seguiremos la versión más sencilla.

Historia

Según Coding Dojo, no se conoce la autoría de la kata¹, pero se considera que fue presentada en sociedad por Michael Feathers y Emily Bache en 2008, en el marco de la conferencia Agile2008.

Enunciado

FizzBuzz es un juego relacionado con el aprendizaje de la división en el que un grupo de estudiantes cuentan los números por turno, reemplazando cada número divisible por tres con la palabra “Fizz” y cada número divisible por cinco con la palabra “Buzz”. Si el número es divisible por ambos, entonces se dice “FizzBuzz”.

Así que nuestro objetivo será escribir un programa que imprima los números del 1 al 100 de tal manera que:

• si el número es divisible por 3 devuelve Fizz.
• si el número es divisible por 5 devuelve Buzz.
• si el número es divisible por 3 y 5 devuelve FizzBuzz.

Orientaciones para resolverla

La kata Fizz Buzz nos va a servir para entender y comenzar a aplicar el ciclo Red-Green-Refactor y las Tres leyes de TDD.

Lo primero que nos conviene hacer es considerar el problema y hacernos una idea general de cómo vamos a solucionarlo. TDD es una estrategia que nos ayuda a evitar la necesidad de hacer un detallado análisis y diseño exhaustivo previo a la solución, pero eso no significa que no debamos primero entender el problema y considerar cómo lo vamos a atacar.

Esto también es necesario para evitar dejarnos llevar por el enunciado literal de la kata, que nos puede llevar a callejones sin salida.

Lo primero que vamos a hacer, una vez que tenemos esa idea general de cómo vamos a enfocar el objetivo, es aplicar la primera ley y escribir un test que falle.

Este test debería definir el primer comportamiento que necesitamos implementar.

Escribir un test que falle significa, en este momento, escribir un test que no va a funcionar porque no existe ningún código que ejecutar, cosa que nos van a decir los mensajes de error. Aunque te parezca absurdo debes intentar ejecutar el test y confirmar que no pasa. Son los mensajes del test los que te van a indicar qué hacer a continuación.

Para conseguir hacer que el test falle tenemos que aplicar la segunda ley, que dice que no podemos escribir un test más grande de lo que sea suficiente para fallar. El test más pequeño posible debería obligarnos a definir la clase instanciándola y poco más.

Por último, para hacer que el test pase, aplicaremos la tercera ley, que dice que no debemos escribir más código de producción que el necesario para que el test pase. Es decir: definir la clase, en su caso el método que vamos a ejercitar y hacer que este devuelva alguna respuesta que finalmente haga pasar el test.

Los dos primeros pasos de esta fase son bastante obvios, pero el tercero no tanto.

Con los dos primeros pasos intentamos llegar a conseguir que el test falle por los motivos adecuados. Es decir, primero falla porque no hemos escrito la clase y, en consecuencia la definimos. Luego fallará porque nos falta el método al que estamos llamando, así que lo definimos. Finalmente, fallará porque no devuelve la respuesta que esperamos, que es lo que queremos llegar a testear.

¿Y qué respuesta deberíamos estar devolviendo en cada caso? Pues ni más ni menos la que espera el test.

Una vez que tenemos un primer test y un primer código de producción que lo hace pasar nos haremos la pregunta: ¿cuál sería el siguiente comportamiento que debería implementar?

Enlaces de interés sobre la kata FizzBuzz

• Vídeo de la kata por Jesús López de la Cruz²
• FizzBuzz en Kata-log³
• FizzBuzz resuelta en SmallTalk⁴
• Code Katas Explained: FizzBuzz⁵
• TDD — Which Order to Write Your Tests⁶
• Solución en Python usando una lista de casos de uso⁷

6 Resolviendo la kata Fizz Buzz

Enunciado de la kata

Nuestro objetivo será escribir un programa que imprima los números del 1 al 100 de tal manera que:

• si el número es divisible por 3 devuelve Fizz.
• si el número es divisible por 5 devuelve Buzz.
• si el número es divisible por 3 y 5 devuelve FizzBuzz.

Lenguaje y enfoque

Esta kata la vamos a hacer en Python con unittest como librería de testing. La tarea consiste crear una clase FizzBuzz, que tendrá un método generate para crear la lista, de modo que se usará más o menos así:

fizzbuzz = Fizzbuzz()
print(fizzbuzz.generate())

Para ello creo una carpeta fizzbuzzkata y dentro añado el archivo fixzzbuzz_test.py.

Definir la clase

Lo que nos pide el ejercicio es obtener una lista de los números 1 al 100 cambiando algunos de ellos por las palabras ‘Fizz’, ‘Buzz’ o ambas en caso de cumplirse ciertas condiciones.

Fíjate que no nos pide una lista de cualquier cantidad de números, sino específicamente del 1 al 100. Volveremos a eso dentro de un momento.

Ahora vamos a concentrarnos en ese primer test. Lo menos que podemos hacer es que se pueda instanciar un objeto del tipo FizzBuzz. He aquí un posible primer test:

import unittest


class FizzBuzzTestCase(unittest.TestCase):
    def test_something(self):
        FizzBuzz()


if __name__ == '__main__':
    unittest.main()

Puede parecer extraño. Este test se limita a intentar instanciar la clase y nada más.

Este primer test debería ser suficiente para fallar, que es lo que dice la segunda ley, y forzarnos a definir la clase para que el test pueda pasar, cumpliendo la tercera ley. En algunos entornos sería necesaria una aserción, ya que consideran que el test no ha pasado si no se ha verificado explícitamente, cosa que no sucede en Python.

Así que lo lanzamos para ver si es verdad que falla. El resultado, como era de esperar es que el test no pasa, mostrando el siguiente error, el cual es justo el que esperaríamos ver:

NameError: name 'FizzBuzz' is not defined

Para hacer que el test pase, tendremos que definir la clase FizzBuzz, cosa que haremos en el propio archivo del test.

import unittest

class FizzBuzz(object):
    pass

class FizzBuzzTestCase(unittest.TestCase):
    def test_something(self):
        FizzBuzz()


if __name__ == '__main__':
    unittest.main()

Y con esto el test pasará. Ahora que estamos en verde podemos pensar en refactorizar. La clase no tiene código. Pero el test no tiene un nombre adecuado, ahora podríamos cambiarlo:

import unittest

class FizzBuzz:
    pass

class FizzBuzzTestCase(unittest.TestCase):
    def test_can_instantiate(self):
        FizzBuzz()


if __name__ == '__main__':
    unittest.main()

Normalmente, es mejor que las clases estén en su propio archivo (o módulo en Python) porque es más fácil gestionar el código y saber dónde está cada cosa. Definitivamente, no queremos el código de producción en el archivo del test, así que creamos el archivo fizzbuzz.py moviendo de paso la clase.

Y en el test, la importamos:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    def test_can_instantiate(self):
        FizzBuzz()


if __name__ == '__main__':
    unittest.main()

Al introducir este cambio y ejecutar el test podemos ver que ahora sí pasa y ya estamos en verde.

Hemos cumplido las tres leyes y cerrado nuestro primer ciclo test-código-refactor. No hay mucho más que podamos hacer aquí, salvo pasar al siguiente test.

Definir el método generate

La clase FizzBuzz no solo no hace nada, ni siquiera tiene métodos. Hemos dicho que queremos que tenga un método generate que es el que devolverá la lista de los números del 1 al 100.

Para forzarnos a escribir el método generate, tenemos que escribir un test que lo llame. El método tendrá que devolver algo, ¿no? No. No siempre es necesario que devuelva algo. Nos basta con que nada se rompa al llamar al método.

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    def test_can_instantiate(self):
        FizzBuzz()

    def test_responds_to_generate_message(self):
        fizzbuzz = FizzBuzz()
        fizzbuzz.generate()


if __name__ == '__main__':
    unittest.main()

Al ejecutar el test nos dice que no tiene ningún método generate:

AttributeError: 'FizzBuzz' object has no attribute 'generate'

Por supuesto que no lo tiene, tenemos que añadirlo:

class FizzBuzz(object):
    def generate(self):
        pass

Ahora ya tenemos una clase capaz de responder al mensaje generate. ¿Podemos hacer algún refactor aquí?

Pues sí, pero no en el código de producción, sino en los tests. Resulta que este test que acabamos de escribir se superpone al anterior. Es decir, el test test_responds_to_generate_message cubre al test test_can_instantiate, convirtiéndolo en redundante. Por tanto, lo podemos quitar:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    def test_responds_to_generate_message(self):
        fizzbuzz = FizzBuzz()
        fizzbuzz.generate()


if __name__ == '__main__':
    unittest.main()

Quizá esto te sorprenda. Es lo que comentamos al principio del libro, algunos de los tests que utilizamos para dirigir el desarrollo dejan de tener utilidad por un motivo u otro, generalmente porque son redundantes y no aportan ninguna información que no nos estén dando otros tests.

Definir un comportamiento para generate

Específicamente queremos que nos devuelva una lista de números. Pero ahora no hace falta que lo haga con los múltiplos de 3 y 5 convertidos.

El test debe verificar esto, pero debe seguir pasando cuando hayamos desarrollado el algoritmo completo. Lo que podemos verificar es que devuelve una lista de 100 elementos, sin prestar atención a los que contiene exactamente.

Este test nos forzará a darle un comportamiento en respuesta al mensaje generate:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):

    def test_respond_to_generate_message(self):
        fizzbuzz = FizzBuzz()
        fizzbuzz.generate()

    def test_generates_list_of_100_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(100, len(num_list))


if __name__ == '__main__':
    unittest.main()

Por supuesto, el test falla:

TypeError: object of type 'NoneType' has no len()

Ahora mismo, el método devuelve None. Nosotros queremos una lista:

class FizzBuzz(object):
    def generate(self):
        return []

Al hacer que generate devuelva una lista, hacemos que el test falle porque no se cumple lo que esperamos: que la lista tenga un cierto número de elementos:

AssertionError: 100 != 0

Este ya es un error del test. Los anteriores eran básicamente errores equivalentes a los errores de compilación (errores de sintaxis, etc.). Por eso es tan importante ver los tests fallar, para utilizar el feedback que nos proporcionan los mensajes de error.

Hacer que el test pase es bastante fácil:

class FizzBuzz(object):
    def generate(self):
        return [None] * 100

Con el test pasando vamos a pensar un poco.

En primer lugar, se puede argumentar que en este test hemos pedido que la respuesta de generate cumpla dos condiciones:

• ser de tipo list (o array, o collection)
• tener exactamente 100 elementos

Podríamos haber forzado esto mismo con dos tests aún más pequeños.

A estos pequeños pasos se les suele llamar baby steps y lo cierto es que no tienen una medida determinada, sino que dependen de nuestra práctica y experiencia.

Así, por ejemplo, el test que hemos creado es lo bastante pequeño como para no generar un gran salto de código en producción, aunque es capaz de verificar las dos condiciones a la vez.

En segundo lugar, fíjate que hemos escrito tan solo el código necesario para que se cumpla el test. De hecho devolvemos una lista de 100 elementos None, lo cual parece que no tiene mucho sentido, pero es suficiente para nuestro objetivo con este test. Recuerda: no escribas más código del necesario para hacer pasar el test.

En tercer lugar, ya tenemos bastante código escrito, entre test y producción, como para examinarlo y ver si tenemos alguna oportunidad de refactorizar.

La oportunidad más clara de refactor que tenemos ahora mismo es el número mágico 100, que podríamos representar mediante una constante de la clase. De nuevo, cada lenguaje te ofrecerá sus propias opciones:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        return [None] * self._NUMBER_OF_ELEMENTS

Y tenemos alguna en el código de test. Otra vez el test que hemos añadido se superpone e incluye al anterior, por lo que podríamos quitarlo.

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):

    def test_generates_list_of_100_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(100, len(num_list))


if __name__ == '__main__':
    unittest.main()

De igual manera, el nombre del test puede mejorar. En lugar de hacer una referencia a la cifra concreta, podríamos simplemente indicar algo más general, que no ate el test a un detalle específico de la implementación:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(100, len(num_list))


if __name__ == '__main__':
    unittest.main()

Por último, y no menos importante, igualmente tenemos un número mágico 100, al cual le pondremos un nombre:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))


if __name__ == '__main__':
    unittest.main()

Y con esto, hemos terminado un nuevo ciclo en el que ya hemos introducido la fase de refactor.

Generar una lista de números

Nuestra clase FizzBuzz ya puede generar una lista de 100 elementos, pero de momento cada uno de ellos es, literalmente, nada. Es hora de escribir un test que nos fuerce a poner números en esa lista.

Para ellos podríamos esperar que la lista generada contenga los números del 1 al 100. Sin embargo, tenemos un problema: al final del proceso de desarrollo la lista contendrá los números, pero algunos de ellos estarán representados con las palabras Fizz, Buzz o FizzBuzz. Si no tengo esto en cuenta, este tercer test empezará a fallar en cuanto comience a implementar el algoritmo que convierte los números. No parece una buena solución.

Un enfoque más prometedor es: ¿qué números no se verán afectados por el algoritmo? Pues aquellos que no sean múltiplos de 3 o de 5, por tanto podríamos escoger algunos de ellos para verificar que se incluyen en la lista sin transformar.

El más sencillo de todos es el 1, que debería figurar en la primera posición de la lista. Por razones de simetría vamos a hacer que los números se generen como strings.

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual('1', num_list[0])


if __name__ == '__main__':
    unittest.main()

El test es muy pequeño y falla:

None != 1

¿Qué cambio podríamos introducir en el código de producción en este punto para que el test pase? El más obvio podría ser el siguiente:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        return ['1'] * self._NUMBER_OF_ELEMENTS

Lo cierto es que es suficiente como para pasar el test, así que nos vale.

Un problema que tenemos aquí es que el número 1 no aparece como tal en el test. Sí aparece su representación, pero usamos su posición en num_list, que es un array 0-indexed. Vamos a hacer explícito que estamos testeando sobre la representación de un número. Primero introducimos el concepto de posición:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        position = 0
        self.assertEqual('1', num_list[position])


if __name__ == '__main__':
    unittest.main()

Y ahora el de número, así como su relación con posición:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        number = 1
        position = number - 1
        self.assertEqual('1', num_list[position])


if __name__ == '__main__':
    unittest.main()

Ya no necesitamos referirnos a la posición para nada, tan solo al número.

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        number = 1
        self.assertEqual('1', num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Podríamos hacer el test más fácil de leer. Primero separamos la verificación:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        number = 1

        self.__assert_number_is_represented_as(number)

    def __assert_number_is_represented_as(self, number):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual('1', num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Extraemos la representación como parámetro en la aserción y hacemos un inline de number para que sea más fluida la lectura:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')

    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Como ves, hemos trabajado mucho en el test. Ahora será muy barato introducir nuevos ejemplos, lo que nos ayudará a escribir más tests y que el proceso sea más agradable y cómodo.

Seguimos generando números

En realidad todavía no hemos verificado que el método generate nos esté dando una lista de números, así que necesitamos seguir proponiendo nuevos tests que nos fuercen a introducir ese código.

Vamos a asegurarnos de que en la segunda posición aparece el número 2 que es el siguiente más sencillo que no es múltiplo de 3 o de 5:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')

    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Tenemos un nuevo test y también falla, así que vamos a añadir código en producción para que el test pase. Sin embargo, tenemos algunos problemas con esta implementación:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        return ['1'] * self._NUMBER_OF_ELEMENTS

Para intervenir en ella necesitaríamos refactorizarla un poco primero. Como mínimo extraer la respuesta a una variable que podamos manipular antes de devolverla.

Pero como el test ahora mismo está fallando no podemos refactorizar. Antes tenemos que anular o borrar el test que acabamos de crear. Lo más fácil es comentarlo y así no se ejecutará. Recuerda, para hacer refactor es obligatorio que los tests pasen:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_one_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        # self.__assert_number_is_represented_as(2, '2')

    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Ahora sí podemos trabajar:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        num_list = ['1'] * self._NUMBER_OF_ELEMENTS
        return num_list

Y volvemos a activar el test, que ahora falla porque el número dos es representado con un ‘1’. El cambio más sencillo que se me ocurre ahora es este, tan tonto:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        num_list = ['1'] * self._NUMBER_OF_ELEMENTS
        num_list[1] = '2'
        
        return num_list

Lo cierto es que el test está en verde. Sabemos que esta no es la implementación que resolverá el problema completo, pero nuestro código de producción solo está obligado a satisfacer los tests existentes. Por tanto, no nos precipitemos. Veamos qué podemos hacer.

El nombre del test está obsoleto, para empezar, hagámoslo más general:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')

    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Una vez resuelto esto, recordemos que antes vimos que el concepto de número y representación eran necesarios para definir mejor el comportamiento esperado en los tests. Podemos introducirlos ahora en nuestro código de producción:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        num_list = ['1'] * self._NUMBER_OF_ELEMENTS
        
        number = 2
        representation = '2'
        
        num_list[number-1] = representation

        return num_list

Es un primer paso. Se pueden ver las limitaciones de la solución actual. Por ejemplo, ¿por qué tiene un tratamiento especial el 1? ¿Y qué pasará si queremos verificar otro número? Son varios problemas.

En cuanto al número 1, la clave está en la idea de lista de números. Ahora mismo generamos una lista de constantes, pero cada elemento de esa lista debería ser un número correlativo empezando por el número 1, hasta completar el número de elementos.

Y luego tendríamos que reemplazar cada número por su representación. Algo así:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))

        number = 1
        representation = '1'

        num_list[number-1] = representation

        number = 2
        representation = '2'

        num_list[number-1] = representation

        return num_list

El test sigue pasando con esta nueva estructura, pero esto no parece muy práctico. Sin embargo, podemos ver un patrón. Necesitamos recorrer la lista para darle una solución:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
        for number in num_list:
            if number == 1:
                representation = '1'

            if number == 2:
                representation = '2'

            num_list[number-1] = representation

        return num_list

Con la información de que disponemos, podríamos asumir simplemente que nos basta con convertir el número en string y ponerlo en su lugar:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
        for number in num_list:
            representation = str(number)
            num_list[number-1] = representation

        return num_list

Claro que existen formas más pythonicas y compactas, como esta:

class FizzBuzz:

    _NUMBERS_IN_LIST = 100
    
    def generate(self):
        return list(map(lambda num: str(num + 1), range(self._NUMBERS_IN_LIST)))

Pero debemos tener cuidado, probablemente estamos adelantándonos demasiado con este refactor y seguramente nos generará problemas cuando intentemos avanzar. Por eso, es preferible mantener una implementación más directa e ingenua y dejar las optimizaciones y estructuras más avanzadas para cuando el comportamiento del método esté completamente definido. Así que te recomendaría evitar este tipo de aproximación.

Todo este refactor con los tests pasando. Esto quiere decir que:

1. Con el test describimos el comportamiento que queremos desarrollar
2. Hacemos pasar el test con el código más sencillo posible, por estúpidamente simple que nos parezca, a fin de tener ese comportamiento implementado
3. Usamos los test en verde como red de seguridad para reestructurar el código hasta encontrar un diseño mejor: fácil de entender, mantener y extender.

Los puntos 2 y 3 se construyen basándose en estos principios:

• KISS: Keep it simply stupid (mantenlo simplemente estúpido), que quiere decir mantener el sistema lo más tonto posible, y no intentar añadir inteligencia prematuramente. Cuanto más mecánico y simple mejor, dentro de sus necesidades. Este KISS es nuestra primera aproximación.
• Ley de Gall: todo sistema complejo que funciona ha evolucionado desde un sistema más simple que funcionaba. Por tanto, empezamos por una implementación muy simple que funcione (KISS) y la hacemos evolucionar hacia una más compleja que también funciona, cosa que sabemos gracias a que el test sigue pasando.
• YAGNI: Your aren’t gonna need it (no lo vas a necesitar), que nos fuerza a no implementar más comportamiento que lo estrictamente necesario para que pasen los tests actuales.

Pero ahora tenemos que implementar nuevos comportamientos.

El test que no falla

El siguiente número que no es múltiplo de 3, 5 o 15 es 4, así que añadimos un ejemplo para eso:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')
        self.__assert_number_is_represented_as(4, '4')

    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Y el test pasa. ¿Buena noticia? Depende. Un test que pasa nada más crearlo siempre es motivo de sospecha, al menos desde el punto de vista de TDD. Recuerda: escribir un test que falle es lo primero. Si el test no falla es que:

• El comportamiento ya está implementado
• No es el test que andábamos buscando

En nuestro caso ocurre que el último refactor ha dado lugar al comportamiento general de los números que no necesitan transformación. De hecho, podemos categorizar los números en estas clases:

• Números que se representan como ellos mismos
• Múltiplos de tres, representados por ‘Fizz’
• Múltiplos de cinco, representados por ‘Buzz’
• Múltiplos de tres y cinco, representados por ‘FizzBuzz’

1 y 2 son miembros de la primera clase, por lo que son ejemplos más que suficientes, ya que cualquier número de esa clase nos valdría como ejemplo. En TDD los necesitamos porque nos han ayudado a introducir la idea de que tendríamos que recorrer la lista de números. Pero nos bastaría con un único test en QA. Por eso, al introducir el ejemplo del 4, no hace falta añadir nuevo código: el comportamiento ya está implementado.

Es hora de moverse a las otras clases de números.

Aprendiendo a decir “Fizz”

Es hora de que nuestro FizzBuzz sea capaz de convertir el 3 en “Fizz”. Un test mínimo para especificarlo sería el siguiente:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')
        self.__assert_number_is_represented_as(4, '4')

    def test_three_and_its_multiples_are_represented_as_fizz(self):
        self.__assert_number_is_represented_as(3, 'Fizz')


    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Teniendo un test que falla, veamos qué código de producción mínimo podríamos añadir para que pase:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
        for number in num_list:
            representation = str(number)

            if number == 3:
                representation = 'Fizz'

            num_list[number - 1] = representation

        return num_list

Hemos añadido un if que hace pasar este caso particular. De momento no hay otra forma mejor con la información que tenemos. Recuerda KISS, Gall y YAGNI para evitar avanzar más de lo debido.

En lo que toca al código, puede que haya una manera mejor de poblar la lista. En lugar de generar una lista de números y cambiarla, tal vez podamos iniciar una lista vacía e ir añadiendo las representaciones de los números en ella:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        num_list = list(range(1, self._NUMBER_OF_ELEMENTS + 1))
        for number in num_list:
            representation = str(number)

            if number == 3:
                representation = 'Fizz'

            representations.append(representation)

        return representations

Esto funciona. Ahora num_list no tiene mucha razón de ser como lista. Podemos hacer un cambio:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        num_list = range(1, self._NUMBER_OF_ELEMENTS + 1)
        for number in num_list:
            representation = str(number)

            if number == 3:
                representation = 'Fizz'

            representations.append(representation)

        return representations

Y eliminar la variable temporal:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number == 3:
                representation = 'Fizz'

            representations.append(representation)

        return representations

Todo sigue funcionando correctamente, como atestiguan los tests.

Decir “Fizz” cuando toca

Ahora queremos que nos ponga un “Fizz” cuando el número es múltiplo de 3 y no solo cuando es exactamente 3. Por supuesto, nos toca añadir un test para especificarlo. Esta vez con el número 6, que es el más cercano que tenemos y que es múltiplo de 3 (y no de cinco).

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')
        self.__assert_number_is_represented_as(4, '4')

    def test_three_and_its_multiples_are_represented_as_fizz(self):
        self.__assert_number_is_represented_as(3, 'Fizz')
        self.__assert_number_is_represented_as(6, 'Fizz')


    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Para hacer pasar el test el cambio que hay que hacer es bastante pequeño. Tenemos que modificar la condición para ampliarla a los múltiplos de tres. Pero vamos a hacerlo de manera progresiva.

Primero establecemos el comportamiento:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number == 3:
                representation = 'Fizz'

            if number == 6:
                representation = 'Fizz'

            representations.append(representation)

        return representations

Con esto el test, pasa. Ahora vamos a cambiar el código para que use el concepto múltiplo de:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number == 3:
                representation = 'Fizz'

            if number == 6:
                representation = 'Fizz'

            if number % 3 == 0:
                representation = 'Fizz'

            representations.append(representation)

        return representations

El test sigue pasando, lo que indica que nuestra hipótesis es correcta. Ahora podemos eliminar la parte de código redundante:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number % 3 == 0:
                representation = 'Fizz'

            representations.append(representation)

        return representations

En este punto, podrías querer probar otros ejemplos de la misma clase, aunque realmente no es necesario dado que cualquier múltiplo de tres es un representante adecuado. Por eso, nos moveremos al siguiente comportamiento.

Aprendiendo a decir “Buzz”

Este test nos permite especificar el nuevo comportamiento:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')
        self.__assert_number_is_represented_as(4, '4')

    def test_three_and_its_multiples_are_represented_as_fizz(self):
        self.__assert_number_is_represented_as(3, 'Fizz')
        self.__assert_number_is_represented_as(6, 'Fizz')

    def test_five_and_its_multiples_are_represented_as_buzz(self):
        self.__assert_number_is_represented_as(5, 'Buzz')

    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Así que modificamos el código de producción para lograr que pase el test. Como hemos hecho antes, tratamos el caso particular de forma particular:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number % 3 == 0:
                representation = 'Fizz'

            if number == 5:
                representation = 'Buzz'

            representations.append(representation)

        return representations

Sí, ya sabemos cómo tendríamos que tratar el caso general de los múltiplos de cinco, pero es preferible forzarse a ir despacio. Recuerda que el objetivo principal del ejercicio no es resolver la generación de la lista, sino hacerlo guiadas por tests. Nuestro interés ahora es internalizar este ciclo de pasos cortos.

No hay mucho más que podamos hacer ahora, salvo pasar al siguiente test.

Decir “Buzz” cuando toca

A estas alturas el test es bastante obvio, el siguiente múltiplo de 5 es 10:

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')
        self.__assert_number_is_represented_as(4, '4')

    def test_three_and_its_multiples_are_represented_as_fizz(self):
        self.__assert_number_is_represented_as(3, 'Fizz')
        self.__assert_number_is_represented_as(6, 'Fizz')

    def test_five_and_its_multiples_are_represented_as_buzz(self):
        self.__assert_number_is_represented_as(5, 'Buzz')
        self.__assert_number_is_represented_as(10, 'Buzz')

    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Y, de nuevo, el cambio en el código de producción es simple al principio:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number % 3 == 0:
                representation = 'Fizz'

            if number == 5:
                representation = 'Buzz'

            if number == 10:
                representation = 'Buzz'

            representations.append(representation)

        return representations

A continuación, procedemos paso a paso en el refactor, ahora que hemos asegurado el comportamiento:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number % 3 == 0:
                representation = 'Fizz'

            if number == 5:
                representation = 'Buzz'

            if number == 10:
                representation = 'Buzz'
                
            if number % 5 == 0:
                representation = 'Buzz'

            representations.append(representation)

        return representations

Y luego:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number % 3 == 0:
                representation = 'Fizz'

            if number % 5 == 0:
                representation = 'Buzz'

            representations.append(representation)

        return representations

Y con este refactor podemos pasar a la siguiente clase de números.

Aprender a decir “FizzBuzz”

La estructura es exactamente igual. Empecemos por el caso más sencillo: 15 debe devolver “FizzBuzz” ya que 15 es el primer número que es múltiplo de 3 y 5 a la vez

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')
        self.__assert_number_is_represented_as(4, '4')

    def test_three_and_its_multiples_are_represented_as_fizz(self):
        self.__assert_number_is_represented_as(3, 'Fizz')
        self.__assert_number_is_represented_as(6, 'Fizz')

    def test_five_and_its_multiples_are_represented_as_buzz(self):
        self.__assert_number_is_represented_as(5, 'Buzz')
        self.__assert_number_is_represented_as(10, 'Buzz')

    def test_fifteen_and_its_multiples_are_represented_as_fizzbuzz(self):
        self.__assert_number_is_represented_as(15, 'FizzBuzz')


    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

El nuevo test falla. Hagámoslo pasar:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number % 3 == 0:
                representation = 'Fizz'

            if number % 5 == 0:
                representation = 'Buzz'

            if number == 15:
                representation = 'FizzBuzz'

            representations.append(representation)

        return representations

Decir “FizzBuzz” cuando toca

Y seguimos introduciendo un test para otro caso de la clase de múltiplos de 3 y 5, que será 30.

import unittest

from fizzbuzzkata.fizzbuzz import FizzBuzz


class FizzBuzzTestCase(unittest.TestCase):
    _NUMBER_OF_ELEMENTS = 100

    def test_generates_list_of_required_number_of_elements(self):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(self._NUMBER_OF_ELEMENTS, len(num_list))

    def test_number_is_represented_as_itself(self):
        self.__assert_number_is_represented_as(1, '1')
        self.__assert_number_is_represented_as(2, '2')
        self.__assert_number_is_represented_as(4, '4')

    def test_three_and_its_multiples_are_represented_as_fizz(self):
        self.__assert_number_is_represented_as(3, 'Fizz')
        self.__assert_number_is_represented_as(6, 'Fizz')

    def test_five_and_its_multiples_are_represented_as_buzz(self):
        self.__assert_number_is_represented_as(5, 'Buzz')
        self.__assert_number_is_represented_as(10, 'Buzz')

    def test_fifteen_and_its_multiples_are_represented_as_fizzbuzz(self):
        self.__assert_number_is_represented_as(15, 'FizzBuzz')
        self.__assert_number_is_represented_as(30, 'FizzBuzz')


    def __assert_number_is_represented_as(self, number, representation):
        fizzbuzz = FizzBuzz()
        num_list = fizzbuzz.generate()
        self.assertEqual(representation, num_list[(number - 1)])


if __name__ == '__main__':
    unittest.main()

Esta vez iré directamente a la implementación final, pero ya te haces a la idea:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        representations = list()
        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)

            if number % 3 == 0:
                representation = 'Fizz'

            if number % 5 == 0:
                representation = 'Buzz'

            if number % 15 == 0:
                representation = 'FizzBuzz'

            representations.append(representation)

        return representations

¡Y ya tenemos nuestro “FizzBuzz”!

Finalizando

Hemos completado el desarrollo del comportamiento especificado de la clase FizzBuzz. De hecho, cualquier test que añadamos ahora nos confirmará que el algoritmo es lo bastante general como para que todos los casos estén cubiertos. Es decir, no hay un test concebible que nos pueda obligar a introducir más código de producción: no hay nada más que debamos hacer.

En un caso de trabajo real este código sería funcional y entregable. Pero ciertamente podemos mejorarlo todavía. Todos los tests pasando indican que el comportamiento deseado está implementado, así que podríamos refactorizar sin miedo buscando una solución más flexible. Por ejemplo, con la siguiente solución sería fácil añadir algunas reglas más:

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def generate(self):
        rules = {
            3: 'Fizz',
            5: 'Buzz',
            15: 'FizzBuzz',
        }

        representations = list()

        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)
            for divisor in rules.keys():
                if number % divisor == 0:
                    representation = rules[divisor]

            representations.append(representation)

        return representations

Y si te fijas bien, sería relativamente fácil modificar la clase para introducir las reglas desde fuera, ya que bastaría con pasar el diccionario con las reglas al instanciar la clase, cumpliendo el principio de Open for extension and Closed for modification. En este caso, hemos dejado que se usen las reglas originales si no se indican otras, de modo que los tests siguen pasando exactamente igual.

class FizzBuzz(object):
    _NUMBER_OF_ELEMENTS = 100

    def __init__(self, rules=None):
        if rules is None:
            rules = {
                3: 'Fizz',
                5: 'Buzz',
                15: 'FizzBuzz',
            }
        self.rules = rules

    def generate(self):

        representations = list()

        for number in range(1, self._NUMBER_OF_ELEMENTS + 1):
            representation = str(number)
            for divisor in self.rules.keys():
                if number % divisor == 0:
                    representation = self.rules[divisor]

            representations.append(representation)

        return representations

Qué hemos aprendido con esta kata

• Las leyes de TDD
• El ciclo red->green->refactor
• Usar tests mínimos para hacer avanzar el código de producción
• Cambiar el código de producción lo mínimo para conseguir el comportamiento
• Usar la fase de refactor para mejorar el diseño del código

7 Elección de los ejemplos y criterio de finalización

Una de las preguntas más frecuentes cuando empiezas a hacer TDD es cuántos tests tienes que escribir hasta considerar el desarrollo terminado. La respuesta corta es: tendrás que hacer todos los tests que sean necesarios y ni uno más. La respuesta larga es este capítulo.

Checklist driven testing

Una buena técnica puede ser seguir el consejo de Kent Beck y escribir una lista de control o check-list en la que anotamos todos aquellos comportamientos que queremos implementar. Obviamente, a medida que completamos cada comportamiento vamos tachando items en la lista.

También es posible que, durante el trabajo, descubramos que necesitamos testear algún otro comportamiento, que podemos suprimir alguno de los elementos de la lista, o que nos interesa cambiar el orden en que lo hemos planeado. Por supuesto que podemos hacer todo esto según nos convenga.

La lista no es más que una herramienta para no depender de nuestra memoria durante el proceso. Al fin y al cabo, uno de los beneficios de hacer Test Driven Development es reducir la cantidad de información y conocimiento que tenemos que utilizar en cada fase del proceso de desarrollo. Cada ciclo de TDD implica un problema muy pequeño, que podemos resolver con bastante poco esfuerzo. Pequeños pasos que acaban llevándonos muy lejos.

Veamos un ejemplo con la kata Leap Year, en la que tenemos que crear una función para calcular si un año es bisiesto o no. Una posible lista de control sería esta:

Checklist para Leap Year

* Los años que no pueden dividir por 4 son años normales
* Los años divisibles por 4 son bisiestos
* Si son divisibles por 100 son bisiestos
* Si son divisibles por 400 entonces no son bisiestos

Otro ejemplo para la kata Prime Numbers, en la que el ejercicio consiste en desarrollar una función que obtenga los factores primos de un número:

Checklist para Prime Numbers

* Números que no tienen factores primos
* Números primos (el único factor primo es el mismo número)
* Números no primos:
   * Potencias de un solo factor primo
   * Producto de distintos factores primos

Selección de ejemplos

Por cada comportamiento que queremos implementar necesitaremos un cierto número de ejemplos con los que escribir los tests. En el capítulo siguiente veremos que TDD tiene dos momentos principales: uno relacionado con el establecimiento de la interfaz de la unidad que estamos creando y otro en el que desarrollamos el comportamiento propiamente dicho. Es en este momento cuando necesitamos ejemplos que cuestionen la implementación existente y nos obliguen a introducir código que produzca el comportamiento deseado.

Una buena idea es, por tanto, anotar varios ejemplos posibles con los que probar cada item de la lista de control.

Pero, ¿cuántos ejemplos son necesarios? En QA tenemos varias técnicas para escoger ejemplos representativos con los que generar los tests, pero tienen el objetivo de optimizar la relación entre el número de tests y su capacidad de cubrir los escenarios posibles.

Podemos utilizar algunas de ellas en TDD, aunque de una forma un poco diferente, como veremos a continuación. Ten en cuenta que en TDD estamos desarrollando un algoritmo y, en muchos casos, lo vamos descubriendo mientras lo escribimos. Para eso necesitaremos varios ejemplos relacionados con el mismo comportamiento, de modo que podamos identificar regularidades y descubrir cómo generalizarlo.

Las técnicas en las que nos vamos a fijar son:

Partición por clase de equivalencia

Esta técnica se basa en que el conjunto de todos los posibles casos concebibles se puede dividir en clases mediante algún criterio. Todos los ejemplos en la misma clase serían equivalentes, por lo que bastaría hacer un test con un ejemplo de cada clase, ya que todos son igualmente representativos de la misma.

Análisis de límites

Esta técnica es similar a la anterior, pero prestando atención a los límites o fronteras entre clases. Se escogen dos ejemplos de cada clase que son justamente los que se encuentran en sus límites. Ambos ejemplos son representativos de la clase, pero nos permiten estudiar qué ocurre en los extremos del intervalo.

Se usa cuando los ejemplos son datos contínuos o nos importa especialmente el cambio que se produce al pasar de una clase a otra. Específicamente es el tipo de situación en la que el resultado depende de si el valor considerado es mayor o estrictamente mayor, etc.

Tabla de decisión

La tabla de decisión no es más que el resultado de combinar los posibles valores, agrupados en clases, de los parámetros que se pasan a la unidad bajo test.

Vamos a ver la elección de ejemplos aplicada al caso de Leap Year. Para eso, empezamos con la lista:

Checklist para Leap Year

* Los años que no pueden dividir por 4 son años normales
* Los años divisibles por 4 son bisiestos
* Si son divisibles por 100 son bisiestos
* Si son divisibles por 400 entonces no son bisiestos

Veamos el primer item. Podríamos usar cualquier número que cumpla la condición de no ser divisible por 4:

* Los años que no pueden dividir por 4 son años normales

Ejemplos: 1997, 2021, 1825

En el segundo item, los ejemplos deben cumplir la condición de ser divisibles por 4:

* Los años divisibles por 4 son bisiestos

Ejemplos: 1996, 2000, 2020, 1600, 1800, 1900

Prestemos atención al siguiente elemento de la lista. La condición de ser números divisibles por 100 se superpone con la condición anterior. Por tanto, tenemos que eliminar algunos ejemplos del item anterior:

* Los años divisibles por 4 son bisiestos

Ejemplos: 1996, 2020

* Si son divisibles por 100 son bisiestos

Ejemplos: 2000, 1600, 1800, 1900

Y ocurre lo mismo con el último de los elementos de la lista. Los ejemplos para este item son los números divisibles por 400. También se superpone con el ejemplo anterior:

* Si son divisibles por 100 son bisiestos

Ejemplos: 1800, 1900

* Si son divisibles por 400 entonces no son bisiestos

Ejemplos: 1600, 2000

De este modo, la lista con los ejemplos quedaría así:

* Los años que no pueden dividir por 4 son años normales

Ejemplos: 1997, 2021, 1825

* Los años divisibles por 4 son bisiestos

Ejemplos: 1996, 2020

* Si son divisibles por 100 son bisiestos

Ejemplos: 1800, 1900

* Si son divisibles por 400 entonces no son bisiestos

Ejemplos: 1600, 2000

Por otro lado, la elección de ejemplos para Prime Factors nos podría dar esto:

Checklist para Prime Numbers

* Números que no tienen factores primos

Ejemplos: 1

* Números primos (el único factor primo es el mismo número)

Ejemplos: 2, 3, 5...

* Números no primos:
   * Potencias de un solo factor primo
   
   Ejemplos: 4, 8, 9, 16, 27...
   
   * Producto de distintos factores primos
   
   Ejemplos: 6, 10, 12, 15, 18, 20...

Uso de varios ejemplos para generalizar un algoritmo

En ejercicios de código simples como puede ser la kata Leap Year, es relativamente fácil anticipar el algoritmo, de modo que no necesitaríamos usar varios ejemplos para hacerlo evolucionar e implementarlo. En realidad, sería suficiente con un ejemplo de cada clase, como hemos visto al hablar de la partición por clases de equivalencia, y en pocos minutos tendríamos el problema resuelto.

Sin embargo, si estamos empezando con TDD es buena idea ir paso a paso. Lo mismo que si nos enfrentamos a un comportamiento complejo. Es preferible tomar baby steps realmente pequeños, introducir varios ejemplos y esperar a tener suficiente información para generalizar. En este mismo libro puedes encontrar varias aplicaciones de esta técnica. Tener algo de duplicación de código es preferible a escoger la abstracción equivocada y construir sobre ella.

Una heurística que puedes aplicar es la regla de los tres. Esta regla nos dice que no deberíamos intentar generalizar código hasta tener al menos tres repeticiones del mismo. Para ello, tendremos que identificar las partes fijas y las partes que cambian.

Considera este ejemplo, tomado de un ejercicio de la kata Leap Year. En este punto los tests están pasando, pero de momento no hemos generado un algoritmo.

function leapYear(year) {
    if (year === 1992) {
        return true;
    }
    if (year === 1996) {
        return true;
    }
    if (year === 2020) {
        return true;
    }

    return false;
}

describe('Identify Leap Year', () => {
    it('should be Leap Year', () => {
        expect(leapYear(1992)).toBeTruthy();
        expect(leapYear(1996)).toBeTruthy();
        expect(leapYear(2020)).toBeTruthy();
    });
})

Ya tenemos tres repeticiones. ¿Qué tienen en común aparte de la estructura if/then?. Forcemos un pequeño cambio:

function leapYear(year) {
    if (year === 498 * 4) {
        return true;
    }
    if (year === 499 * 4) {
        return true;
    }
    if (year === 505 * 4) {
        return true;
    }

    return false;
}

describe('Identify Leap Year', () => {
    it ('should be Common Year', () => {
        expect(leapYear(1997)).toBeFalsy();
        expect(leapYear(1998)).toBeFalsy();
        expect(leapYear(2021)).toBeFalsy();
    });
	
    it('should be Leap Year', () => {
        expect(leapYear(1992)).toBeTruthy();
        expect(leapYear(1996)).toBeTruthy();
        expect(leapYear(2020)).toBeTruthy();
    });
})

Claramente, los tres años son divisibles por 4. Así que podríamos expresarlo de otra manera:

function leapYear(year) {
    if (year % 4 === 0) {
        return true;
    }
    if (year % 4 === 0) {
        return true;
    }
    if (year % 4 === 0) {
        return true;
    }

    return false;
}

describe('Identify Leap Year', () => {
    it ('should be Common Year', () => {
        expect(leapYear(1997)).toBeFalsy();
        expect(leapYear(1998)).toBeFalsy();
        expect(leapYear(2021)).toBeFalsy();
    });
	
    it('should be Leap Year', () => {
        expect(leapYear(1992)).toBeTruthy();
        expect(leapYear(1996)).toBeTruthy();
        expect(leapYear(2020)).toBeTruthy();
    });
})

Que ahora es una repetición obvia y se puede eliminar:

function leapYear(year) {
    if (year % 4 === 0) {
        return true;
    }

    return false;
}

describe('Identify Leap Year', () => {
    it ('should be Common Year', () => {
        expect(leapYear(1997)).toBeFalsy();
        expect(leapYear(1998)).toBeFalsy();
        expect(leapYear(2021)).toBeFalsy();
    });
	
    it('should be Leap Year', () => {
        expect(leapYear(1992)).toBeTruthy();
        expect(leapYear(1996)).toBeTruthy();
        expect(leapYear(2020)).toBeTruthy();
    });
})

Esto ha sido muy obvio, por supuesto. Sin embargo, no siempre tendremos las cosas tan fáciles.

En resumen, si no conocemos muy bien el problema, puede ser útil esperar a que se cumpla la regla de los tres para empezar a pensar en generalizaciones del código. Esto implica que, como mínimo, introduciremos tres ejemplos que representen la misma clase antes de refactorizar la solución a una más general.

Veamos otro ejemplo en la misma kata:

function leapYear(year) {
    if (year % 100 === 0) {
        return false;
    }

    if (year % 4 === 0) {
        return true;
    }

    return false;
}

describe('Identify Leap Year', () => {
    it ('should be Common Year', () => {
        expect(leapYear(1997)).toBeFalsy();
        expect(leapYear(1998)).toBeFalsy();
        expect(leapYear(2021)).toBeFalsy();
    });
	
    it('should be Leap Year', () => {
        expect(leapYear(1992)).toBeTruthy();
        expect(leapYear(1996)).toBeTruthy();
        expect(leapYear(2020)).toBeTruthy();
    });

    it('should be exceptional common year', function () {
        expect(leapYear(1700)).toBeFalsy();
        expect(leapYear(1800)).toBeFalsy();
        expect(leapYear(1900)).toBeFalsy();
    });
})

La duplicación que no lo es

El concepto divisible es evidente en esta ocasión y realmente no necesitamos un tercer caso para valorar la posibilidad de extraerlo. Pero aquí lo importante no es la duplicación. En realidad nos hubiese bastado con un ejemplo. Este refactor lo hacemos porque hace explícita la idea de que la condición que se evalúa es el hecho de que el número del año sea divisible por un cierto factor para que se aplique la regla.

function leapYear(year) {
    function divisibleBy(divisor) {
        return year % divisor === 0;
    }

    if (divisibleBy(100)) {
        return false;
    }

    if (divisibleBy(4)) {
        return true;
    }

    return false;
}

describe('Identify Leap Year', () => {
    it ('should be Common Year', () => {
        expect(leapYear(1997)).toBeFalsy();
        expect(leapYear(1998)).toBeFalsy();
        expect(leapYear(2021)).toBeFalsy();
    });
	
    it('should be Leap Year', () => {
        expect(leapYear(1992)).toBeTruthy();
        expect(leapYear(1996)).toBeTruthy();
        expect(leapYear(2020)).toBeTruthy();
    });

    it('should be exceptional common year', function () {
        expect(leapYear(1700)).toBeFalsy();
        expect(leapYear(1800)).toBeFalsy();
        expect(leapYear(1900)).toBeFalsy();
    });
})