Nuestro clon worldle es cada vez mejor,
pero todavía hay un elefante en la habitación
que hemos estado ignorando hasta ahora.
Se supone que un jugador puede intentar adivinar la palabra varias veces.
Más exactamente, un jugador puede intentarlo seis veces.
Hoy vamos a modificar nuestra aplicación para permitir precisamente eso.
Esta prueba de aquí tendrá que ser modificada
para requerir al usuario para hacer seis conjeturas
antes de que se muestre el mensaje de derrota.
Tal vez podríamos hacer uso de de otra función .each para esto.
Vamos a convertir esta prueba en una serie de mini tests
donde pasamos de hacer cero conjeturas erróneas
todo el camino hasta a hacer seis conjeturas erróneas.
Sólo debemos ver el mensaje de derrota cuando hacemos seis conjeturas erróneas.
Así que como puedes ver aquí,
Estoy proporcionando una serie de datos
que va desde cero conjeturas a seis conjeturas,
y sólo en el último caso deberíamos ver un mensaje de derrota.
Un buen nombre para este bloque descriptivo podría ser un mensaje de derrota
debería aparecer si el jugador hace adivinanzas incorrectas seis veces seguidas.
Ahora el cuerpo de este bloque de descripción
va a contener una serie de pruebas automatizadas para cada escenario.
Creo que un buen nombre para cada una de estas pruebas individuales
podría ser por lo tanto para x conjeturas
un mensaje de derrota debería o no debería aparecer.
¿Qué vamos a rellenar en este título dinámico?
Bueno, va a ser algo
que va a ser calculado basado en el número de conjeturas
y si es o no el mensaje de derrota debe ser visible.
Aquí podemos añadir el número de aciertos directamente al nombre de la prueba,
pero aquí quiero renderizar
la palabra no
sólo si el mensaje de derrota es falso.
Genial y cuales serían los arrange actuar y afirmar esta prueba?
Bueno, el arrange ya está hecho por nosotros gracias a nuestro beforeEach,
que es montar el componente con la palabra del día.
Para el acto vamos a escribir una conjetura errónea
un número de conjeturas cantidad de tiempo.
Y para la fase de afirmación
vamos a buscar que el mensaje de derrota está en la pantalla
o no está en la pantalla.
Ahora si ejecutamos nuestras pruebas
podemos ver que estamos pasando en el caso de no mostrar un mensaje de victoria
si no se ha adivinado mal,
pero estamos fallando en todos los reintentos
que el jugador debería tener derecho a hacer.
Usted puede ver que cuando nos equivocamos una vez
ya estamos mostrando el mensaje de derrota al jugador.
Bien, vamos a pasar esta prueba
y por supuesto deberíamos eliminar esta prueba anterior de aquí
porque ya no es relevante para el proyecto.
Ha sido reemplazada por nuestra nueva prueba.
Para que el test pase,
tendremos que llevar un registro
de todas las conjeturas anteriores que el jugador ha enviado.
Bueno conjetura presentado en este momento es sólo una cadena.
Vamos a convertir esto en conjeturas presentadas que ahora es un array de cadenas.
Si el jugador envía una suposición
entonces en lugar de simplemente asignar la suposición a guesseSubmitted
vamos a empujar esta conjetura.
Otro cambio que tenemos que hacer es lo que cuenta como el final del juego.
Antes de que tuviéramos que sólo tenía que ser
guessSubmitted con una longitud mayor que cero,
pero ahora las conjeturas enviadas tienen que tener una longitud de seis o conjeturas presentadas
incluye la palabra del día.
Y vamos a dar el mensaje de victoria
cuando las adivinanzas enviadas incluye la palabra del día.
Nótese que TypeScript se está quejando por aquí
porque la palabra del día puede ser una cadena o indefinida.
La razón de esto es que nuestra palabra del día no es necesaria.
Podemos hacer que se requiera proporcionando una clave extra aquí,
llamada requerida, y ponerla a true.
Y ya está. Puedes ver que TypeScript ha dejado de quejarse
porque ahora la palabra del día se considera una cadena.
¡Estupendo! Creo que esto debería ser suficiente para pasar la prueba.
Intentemos ejecutar todas las pruebas
y podemos ver que tenemos verde en todo el tablero.
¡Impresionante! Vamos a confirmarlo.
Permitir al jugador hacer 6 intentos.
Para refactorizar, Creo que una buena victoria rápida para nosotros aquí
sería extraer este número 6.
Es un número mágico. ¿Y qué representa?
Bueno, representa el,
MAX_GUESSES_COUNT, ¿verdad?
Usemos esto en nuestra prueba.
Y en nuestro worldeBoard.
¡Impresionante! Si ejecutamos nuestras pruebas podemos ver que todavía estamos pasando.
Así que vamos a hacer otro commit.
Extraer constante.
Otra cosa que creo que aumentaría la legibilidad de este componente
es extraer esta condicional aquí en una propiedad computada.
De nuevo, ¿qué representa esto?
Es efectivamente comprobar para ver si el juego ha terminado.
Así que vamos a hacer una propiedad computada que lo represente.
Me gusta que mis variables booleanas comiencen sus nombres con "is" o "has".
En este caso, quiero llamarla isGameOver.
Y vamos a saber si el juego ha terminado o no
cuando el jugador ha agotado su cuenta de aciertos
o si ha acertado.
Para acceder a la palabra del día como apoyo,
Necesito capturar el valor de retorno de defineProps
y usarlo aquí.
¡Estupendo! Intentemos ejecutar nuestras pruebas de nuevo.
Y podemos ver que seguimos pasando.
Quiero hacer un commit y llamarlo extractConditional.
¡Impresionante!
Si queremos, también podemos hacer que nuestra prueba no tenga tantas repeticiones.
Una forma de hacer esto es,
mediante la creación de esta matriz de entradas aquí, dinámicamente,
a través de Array.from, así.
Array.from recibe, como primer argumento,
cualquier cosa que parezca un array.
Así que un objeto con una propiedad de longitud
va a ser algo que Array.from puede trabajar.
Y el segundo argumento es un mapa de devolución de llamada
donde se puede definir lo que va los valores finales de ese array.
El primer argumento es el valor actual.
El segundo argumento es el índice.
Dicho esto, sin embargo, honestamente,
Yo preferiría la versión anterior de cómo teníamos la prueba.
Creo que las pruebas se leían mejor con esa repetición que teníamos antes.
Así que si tú también piensas igual que yo sigue con la repetición.
No toda repetición es mala, especialmente cuando hablamos de pruebas.
Nuestro objetivo aquí es aumentar la legibilidad de la base de código.
Sólo quería mostrarte
que es posible crear conjuntos de datos dinámicos para la descripción de cada uno.
Si ejecuto todas mis pruebas Puedo ver que todavía están pasando.
Por lo tanto, puedo hacer otro commit,
y voy a llamarlo reducirRepeticionesEnPruebas.
Genial, juntos hemos ampliado las reglas del juego
para permitir a nuestros jugadores tener hasta seis conjeturas.