Creo que una buena cosa que podríamos aplicar a continuación
es que aparezca un mensaje de derrota si el usuario se equivoca.
Me doy cuenta de que wordle te permite cometer múltiples errores,
pero quiero mantener las cosas simples por ahora.
Digamos que en nuestro juego worldle,
si aciertas, ganas el juego.
Si tan pronto como usted hace su primera adivinación incorrecta, pierdes el juego.
La mayoría de los marcos de pruebas le permiten escribir pruebas de marcador de posición
donde podemos escribir ideas para el futuro.
Vitest no es una excepción.
Podemos escribir placeholder test en vitest añadiendo la palabra todo después del test.
En este caso, vamos a escribir dos pruebas diferentes aquí.
Uno que diga que aparece un mensaje de derrota
si el usuario hace una suposición incorrecta.
Otro que dice que no aparece ningún mensaje de rango de juego
si el usuario aún no ha adivinado.
Estupendo. ¿Quieres intentar escribir esta prueba por ti mismo?
¿Publicar este vídeo y probarlo?
De acuerdo. Vamos a escribir la implementación de nuestra primera tarea.
Creo que gran parte del trabajo pesado de esta tarea
puede ser copiado sobre de la prueba anterior que tenemos.
Todo lo que queremos cambiar aquí
es que en lugar de hacer una conjetura que coincida con la palabra del día,
hagamos una conjetura que no coincida.
Finalmente, para nuestra fase de búsqueda,
Quiero afirmar que vemos un mensaje de derrota.
Vamos con mejor suerte la próxima vez.
Si ejecutamos nuestras pruebas,
podemos ver que estamos pasando la primera prueba,
pero en esta nueva, estamos fallando.
Esperamos tener más suerte la próxima vez.
Pero vimos que ganaste!,
por cierto, como regla general,
ejecuta siempre el interruptor de prueba completo.
Incluso si usted piensa exactamente qué pruebas están siendo afectadas,
por el trabajo que estás haciendo,
Ejecutar el conmutador de prueba completo te protegerá contra regresiones.
Para pasar esta prueba
Podemos hacer el mismo enfoque que hemos hecho para el mensaje de victoria.
Vamos a ir a nuestro tablero wordle y mostrar siempre el mensaje de derrota.
Así que si ejecutamos nuestras pruebas, podemos ver que hemos vuelto a la etapa verde.
Vamos a hacer un commit.
Mostrar mensaje de derrota.
Ahora, como probablemente estás esperando, volvemos a la fase de refactorización.
Creo que al igual que como hemos hecho con el mensaje de victoria,
podemos reducir la complejidad aquí
mediante la extracción de otra constante que contendrá nuestro mensaje de derrota.
También podemos hacer lo mismo para nuestra prueba.
Si ejecutamos nuestro test, sigue pasando.
Hagamos un commit, extraigamos la constante.
Otra extracción que podemos hacer es para la palabra del día.
Hagámoslo.
Siempre que tengas una clave igual al valor en un objeto,
puedes simplificarlo sólo tener la clave.
Perfecto. Si ejecutamos nuestras pruebas o sigue pasando, estupendo.
Así que vamos a hacer un commit y llamemos a esta variable extract.
Bien, ahora, estamos listos para implementar el cuerpo de nuestro siguiente test.
Una vez más, vamos a hacer uso de nuestras pruebas existentes como referencia.
Por lo tanto, voy a copiar la prueba anterior.
Y en este caso no estamos haciendo ninguna entrada de usuario.
Y esperamos que no vamos a ver
ni el mensaje de victoria
ni el mensaje de derrota.
Y volvemos al escenario rojo
porque estamos viendo esos dos mensajes todo el tiempo.
Para pasar esta prueba, tendremos que hacer un par de cosas.
Tenemos que realizar un seguimiento de la conjetura que el usuario está a punto de presentar.
Y una vez que el usuario envía su conjetura,
la compararemos con la palabra del día.
Si coinciden mostramos el mensaje de victoria.
Si no coinciden mostramos el mensaje de derrota
para realizar un seguimiento de la conjetura que el usuario está escribiendo.
Podemos hacer uso de una ref.
Así que el progreso de adivinar se puede seguir a través de esta ref.
El envío se produce cuando el usuario pulsa la tecla enter.
Vamos a tener otro ref por aquí para la suposición enviada.
Y cuando se pulsa enter
el medidor de conjeturas recibe el valor de la conjetura en curso.
Perfecto. Ahora respecto a mostrar los mensajes,
podemos comprobar si la conjetura presentada
es igual a la palabra del día, entonces mostramos el mensaje de victoria.
En caso contrario, mostramos el mensaje de derrota.
Ahora, esto no va a ser suficiente.
Si ejecutamos nuestras pruebas, podemos ver que seguimos fallando,
porque aunque no enviamos ninguna conjetura,
por lo que ya estamos mostrando el mensaje de derrota al usuario.
Esto es porque una cadena vacía
va a ser diferente de la palabra del día.
Eso eran pruebas.
Vamos a tener que añadir una comprobación adicional aquí
que sólo renderizamos el mensaje
si una conjetura tiene una longitud mayor que cero.
si ejecutas esto, ahora estamos en una etapa verde.
Perfecto. Hagamos un commit.
Mostrar sólo la información del final del juego
después de que el juego haya terminado.
La reducción de la duplicación es una clave clave de la fase refractaria.
Y podemos reducir la duplicación en nuestro conjunto de pruebas.
Observa que cada prueba que tenemos,
comienza con exactamente la misma fase de arreglo.
Extraigamos esta lógica común en un gancho que se ejecuta antes de cada prueba.
Esto se puede hacer en vitest
escribiendo una función llamada beforeEach.
Lo que escribamos en esta función
se garantiza que se ejecute antes de cada una de las pruebas de este grupo.
Fíjate que he hecho que wrapper sea una variable
que está en el contexto de este grupo de descripción.
Usted puede notar que nuestra configuración typescript
no le gusta el hecho de que estamos utilizando un tipo implícito any a nuestro wrapper
porque no estoy definiendo el tipo en este momento.
Pero si vamos a la definición de la función de montaje,
podemos ver que el tipo de retorno puede ser bastante desalentador.
He aquí una pequeña pista tipográfica
que puede ayudarte mucho cuando trabajes con tipos complejos.
Como sabemos que nuestra envoltura siempre va a contener
cualquiera que sea el montaje está regresando,
podemos aprovechar un tipo de utilidad que typescript pone a nuestra disposición
específicamente para este tipo de escenario.
Podemos escribir cada wrapper como tipo de retorno
de la función de montaje.
Y ya está. Así de fácil.
Nuestra envoltura está explícitamente tipada ahora a lo que la función mount devuelva.
Si ejecutamos todas nuestras pruebas podemos ver que están pasando.
Muy bien, ahora vamos a hacer una confirmación.
Extraer la fase arrange a beforeEach.
Otro trozo de código que se repite varias veces
es el acto de tener el tipo de jugador y envíe su conjetura.
Extraigamos esto en un mensaje de ayuda personalizado.
Y en este caso, voy a llamarlo playerSubmitGuess.
Esta función, voy a tener la conjetura
justo aquí.
Y en este caso, estamos pasando la palabra del día.
En este otro caso, por aquí, estamos pasando la palabra WRONG.
Si ejecutamos nuestra tarea,
seguimos pasando.
Esta técnica refractaria de aquí
que acabo de hacer se llama método de extracción,
así, porque nuestras pruebas están pasando
Voy a hacer otro commit y decir, extraer método.
Estupendo. Hemos aprendido diferentes maneras.
Podemos refactorizar nuestro código base para que sea más fácil trabajar con él,
extrayendo constantes y métodos.
También aprendimos cómo podemos aprovechar la belleza y los ganchos de vitest,
para manejar partes comunes de nuestra fase organizada.