El juego de la Vida en TypeScript con TDD y medida de cobertura en Jest

0
442

Antes de empezar recordar que este tutorial forma parte de una cadena de tutoriales en las que pretendo simplemente probar tecnologías actuales. Aquí abajo podrás encontrarlos :

También  me gustaría que vieras este video de 2 minutos para entender dónde estamos y a dónde vamos


Mi equipo es Mac

macOS Catalina
Versión 10.15.2

MacBook Pro (15-inch, 2018)
Procesador 2,9 GHz Intel Core i9 de 6 núcleos
Memoria 32 GB 2400 MHz DDR4
Gráficos Intel UHD Graphics 630 1536 MB


Aunque me propuse un reto construyendo un Arcanoid en TypeScript, que todavía tengo que completar (ver referencias) antes quiero revisar un poquito el lenguaje (recordad que no hablo como experto sino como estudiante).

Un buen ejemplo para manejar arrays y hacer pruebas unitarias y TDD puede ser crear el juego de la vida de Conway: https://es.wikipedia.org/wiki/Juego_de_la_vida

Las reglas son sencillas. Creas dentro de un tablero de un tamaño fijo una semilla (que voy a crear aleatoriamente) que representan células y se gobierna en base a tres reglas.

1 – Si en una casilla vacía hay 3 células alrededor vivas, nace una célula.

2 – Si en una casilla hay una célula vida y alrededor solo 2 o tres vivas, sobrevive.

3 – En cualquier otro caso, la célula de esa casilla muere, por superpoblación.

Para empezar voy a crear un test que voy a llamar tdd.test.ts.

El código lo voy a guardar en índex.ts y para visualizarlo voy a crear una página HTML llamada índex.html.

También crearé un fichero de comandos por si necesito usar alguno desde el terminal.

 

El fichero index.html es sencillo.

Solamente tiene un canvas de 300 x 300 donde pintar los elementos.

Este canvas tiene un id=“areadejuego”

 

 

El fichero índex.ts inicialmente solo va a tener el enlace entre el html y JavaScript.

Como veis, nos hace solamente falta una clase llamada JuegoDeLaVidaTDD

Y necesitamos que tenga un timer y una función que se ejecute periódicamente.

El comportamiento es sencillo: se calculará una nueva generación en cada ciclo y se pintará.

El código nos queda tal que así

Este es el resultado que obtenemos. Un esqueleto donde se han inicializado a 1 aleatoriamente las casillas.

Bueno, tal vez tendríamos que preguntarnos si no le estoy dando antes de empezar demasiada responsabilidad en a la clase del juego porque métodos como inicializaMatrizAleatoria podrían estar en una clase dedicada a operaciones con matrices.

Además, si el constructor de la clase principal requiere un objeto CanvasRenderingContext2D

¿cómo pretendemos pasárselo desde un test? Tendremos acoplada la capa de presentación de la capa de cálculos.

Podríamos desdoblar nuestro código en dos clases, una dedicada a presentación y otra a las estructuras de datos y operaciones.

Vamos ahora a crear la estructura del fichero de test.

Inicialmente vamos a crear una función que nos retorne con certeza si el cálculo de los vecinos vivos de una célula son los correctos.

Para ello, voy a crear un conjunto de datos y voy a llamar a la clase del juego para que me lo calcule y comprobemos que el algoritmo es correcto.

Esta es la matriz inicial

 

 

Primero escribimos el test y lo ejecutamos.

Fallará porque no existen los métodos adecuados en la clase del juego.

Es decir, se llama Test Driven Development o TDD porque el test me dice los métodos que tengo que escribir.

Si ahora aportamos los métodos que faltan.

Ahora falla porque no está haciendo bien el cálculo, ya que siempre retoma 0 calculaVecinosVivos

Por tanto, tenemos que escribir el algoritmo.

Este es el código. Realmente creamos unos índices para recorrer las casillas alrededor y sumar los unos. Tenemos que tener cuidado con los indices en el caso de que la fila o columna sea cero o estemos en la última.

Y ahora podemos incluir todos los test que queramos de un modo sencillo, estando seguro de que el cálculo siempre estará bien o el test nos lo soplará.

Si os fijáis, el porcentaje de cobertura de pruebas automáticas en este caso se está limitando a la función calculaVecinosVivos.

Podemos ampliar la cobertura y también verificar que el resultado de una nueva generación completa es lo que esperamos.

Creamos el método nuevaGeneracion  que luego tendremos que implementar porque nos fallará la compilación.

Para comprobar el resultado creo una matriz resultado1 con lo que tiene que salir y tras procesar la nueva generación verificamos automáticamente.

Por tanto, cuando toquemos en un futuro la función que calcula los vecinos o la nueva generación podremos tener una red de seguridad que nos proporcionarán los test.

Este es el código completo.

Y este es nuestro test.

Podemos configurar Jest para que nos diga la cobertura de código que tenemos en jest.config.js

En la carpeta seleccionada almacenan los resultados.

Y comprobamos la cantidad de veces que se testa cada porción.

Y el porcentaje de cobertura. Recordad que esto es una herramienta y que los números nos pueden llegar a esclavizar. Si decimos “yo no hago código que tenga menos del 80% de cobertura” es posible que trabajemos solo para ese número probando cosas que no hay que probar.

Y podemos ver nuestro resultado, Obviamente animado queda mucho más chulo.

Os puedo decir que es hipnótico ver la progresión de las células en cada partida.

Bueno, espero que os haya gustado. Poner test unitarios en nuestra vida y trabajar desde el principio pensado en ello, como nos obliga TDD tiene efectos secundarios, desacoplar capas y hacer código verificable.

Si veis algún fallo o algo mejorable no dudéis en comentarlo.

Aquí os dejo el enlace al siguiente tutorial:

Configuración de Cucumber.js y Jest-Cucumber en Visual Studio Code con TypeScript

Dejar respuesta

Please enter your comment!
Please enter your name here