Otro punto clave detrás del verdadero juego wordle
es que después de cada envío exitoso
el juego presenta al jugador con algunos comentarios.
Muestra las letras correctas en verde.
También muestra las letras que existen en el mundo
pero que están en el lugar equivocado, en amarillo.
Y por último, las letras que no existen en el mundo, aparecen en gris.
Vamos a poner en práctica que para nuestro juego, también.
Pero antes de empezar, hay una pequeña refactorización que quiero hacer.
Quiero separar las preocupaciones entre,
escribir una conjetura y enviar la conjetura
en dos ayudantes de prueba diferentes.
Efectivamente, esta función de aquí representa al jugador
escribiendo y enviando una conjetura.
Así que vamos a cambiarle el nombre.
Si ejecutamos nuestras pruebas, podemos ver que todavía estamos pasando.
Vamos a hacer un commit.
Renombrar método.
Ahora quiero crear el método helper sólo para escribir.
Y efectivamente representa estas líneas de aquí.
Así que vamos a empezar alineando primero la conjetura de entrada.
Y entonces puedo extraer este trozo de aquí
en un nuevo método que será playerTypesGuess.
Este de aquí representará al jugador pulsando enter.
Bien. Si ejecutamos las pruebas, podemos ver que todavía estamos pasando.
Asombroso. Así que vamos a hacer otra confirmación.
Métodos de ayuda separados
para escribir y enviar conjeturas.
Incluso podemos refactorizar una prueba pasada nuestra
para hacer uso del nuevo método playerTypeGuess.
Dado que esta prueba no está realmente relacionada con el proceso de enviar una prueba.
Ejecuta las pruebas y comprueba que todas pasan.
De acuerdo. Hagamos otro commit.
Dejar de enviar conjeturas en pruebas relacionadas con conjeturas en curso.
De acuerdo. Escribamos nuestro nuevo test de características.
Haré un nuevo bloque de descripción
responsable de las pruebas relacionadas con mostrar pistas al jugador.
Nuestra primera prueba para el bloque de descripción
podría asegurar que las pistas no se muestren hasta que el jugador envíe una sugerencia.
¿Y cómo podríamos escribir esta prueba?
Bueno, una retroalimentación o pista
va a ser representado por este atributo HTML especial
llamado data-letter-feedback.
Así que podemos empezar nuestra prueba
comprobando que nuestro componente no proporciona ninguna pista al principio.
Por cierto, si quieres proporcionar un bonito mensaje de aserción fallida,
puedes introducir un segundo argumento a la función expect.
Así que digamos que en este caso
Quiero un mensaje que diga
La retroalimentación se estaba mostrando antes de que el jugador empezara a escribir su respuesta.
De acuerdo. Ahora, quiero que nuestro jugador empiece a escribir su respuesta
y mientras lo escribe,
no deberían ver que aparezcan pistas.
Así que hagamos que nuestro jugador escriba
cualquier conjetura, o voy a ir con la palabra del día por ahora.
Y en este caso, todavía deben no ver el data-letter-feedback.
Así que lo que voy a hacer es cambiar el mensaje de error dedicado
para decir que la respuesta se produjo mientras el jugador estaba escribiendo su conjetura.
Por último, quiero que mi jugador envíe su conjetura
y sólo entonces quiero ver data-letter-feedback.
Y en este caso, voy a decir que la retroalimentación no fue presentada
después de que el jugador envió su conjetura.
Tenga en cuenta que no estamos probando el estilo.
Nuestra aplicación es responsable
de marcar ciertos elementos DOM con este atributo HTML específico.
Pero nuestras pruebas no se preocupan qué reglas CSS pueden aplicarse
a estos atributos.
Otra cosa que quiero mencionar es que esta prueba de aquí que acabamos de escribir,
viola ese arreglo, acto,
y afirmar la estructura que presenté en las primeras lecciones de este curso.
Esto podría considerarse un olor.
Esta afirmación de aquí que está ocurriendo antes de la fase de acto
es lo que llamamos una pre-afirmación.
Podríamos haber convertido esta pre-afirmación en una prueba específica,
llamado el juego comienza sin que se muestren pistas.
Esta afirmación del medio de aquí también podría ser una nueva prueba dedicada
llamada no se muestran pistas mientras el usuario escribe una conjetura.
Por último, esta afirmación final de aquí
podría ser una prueba llamada pistas se muestran después de que se envíe una conjetura.
Por lo tanto, esta prueba de aquí representa tres pruebas en una.
Quería presentarlo así en esta lección
porque pensé que sería una buena oportunidad para cubrir
mensajes de error personalizados
y también porque ha habido ciertos casos en mi carrera como desarrollador
donde he llegado a la conclusión de que tener una prueba con múltiples afirmaciones
estaba proporcionando una mayor legibilidad a mi interruptor de prueba.
Dicho esto, para este caso particular de aquí,
Yo personalmente preferiría dividir esta prueba en tres diferentes,
pero voy a mantener esta base de código exactamente así,
¿cuál prefieres?
¿Le gustaría dividir esta prueba en varias?
Pruébalo. Definitivamente es un enfoque válido.
Si ejecutamos nuestras pruebas, podemos ver que estamos fallando
porque la retroalimentación no se presentó después de que el jugador envió su conjetura.
Para conseguir que pase, podríamos hacer uso de de nuestra prop shouldFlip
que escribimos en el último episodio.
Después de todo, es volteando las cartas
que el juego wordle presenta retroalimentación a su jugador.
Bien, ahora mismo, nuestras pruebas
sólo nos obligan a escribir cualquier tipo de feedback.
Por lo tanto, lo que voy a hacer es si debe voltear se proporciona y veraz,
Voy a dar una respuesta de desconocido.
Si "should flip" es falso, no mostraré la respuesta.
Si ejecuto las pruebas podemos ver que ahora estamos pasando.
Vamos a hacer un commit.
Mostrar respuesta desconocida al enviar la suposición con éxito.
Para la refactorización, podríamos argumentar que shouldFlip es un nombre bastante malo,
ya que dar la vuelta es sólo una elección estilística para la forma en que revisamos la retroalimentación.
Podríamos renombrar esta prop a shouldShowFeedback.
Este sería probablemente un nombre mucho mejor para una proposición booleana con este rol.
Dicho esto, No voy a hacer este cambio de nombre en este momento,
porque nuestra próxima prueba nos llevará hacia la prestación de retroalimentación adecuada
de acuerdo con la palabra del día,
por lo que un booleano prop simplemente no será suficiente.
¡Estupendo! No sólo hemos refactorizado nuestro código base un poco más,
sino que también empezamos a aplicar esa carta de retroalimentación
sólo se debe dar una vez que una conjetura se presenta con éxito.