Antes de empezar a escribir nuestras pruebas,
Quiero que hagamos una rápida a nuestras configuraciones.
Vitest nos permite hacer uso de sus funciones como describir,
esperar, y sin tener que que importarlas nosotros mismos,
cada vez que los necesitemos. Τo do this, we need to enable globals.
Podemos hacerlo yendo a nuestro vitest.config
y poniendo la bandera de globals a true, así
Finalmente, ya que estábamos usando typescript
deberíamos hacer saber al intérprete que vitest globals está disponible.
Para ello, tenemos que ir a nuestro tsconfig.vitest.json,
y añadir un tipo extra vitest/globals.
Perfecto. Ahora podemos volver a nuestra prueba y borrar esta sentencia import.
Si intento ejecutarlos
puedes ver que siguen pasando.
Estupendo. Deberíamos estar listos para hacer un commit ahora.
Ahora, voy a llamar a este commit, usar vitest globals.
Ahora vamos a empezar a escribir nuestra primera prueba.
Como cubrimos en la primera lección,
un principio clave detrás del desarrollo basado en pruebas
es el rojo verde refactorizar el bucle de desarrollo.
Esto significa que el primer paso
tomará para conseguir nuestro juego worldle implementado
es escribir la primera prueba con nuestros requisitos
que queremos que cumpla nuestra aplicación.
Ya que estamos haciendo un clon del mundo,
Yo diría que un buen primer requisito
podría ser que si un usuario hace una conjetura que coincida con la palabra del día,
deberíamos mostrarle un mensaje de victoria.
Hagamos esto.
Cuando estoy pensando en un nombre para una prueba,
Me gusta pensar en un nombre que,
incluso alguien que es un juez puede entender.
Además, trato de evitar usar palabras como correcto e incorrecto,
porque por sí mismas, no tienen mucho significado.
Me gusta explicar lo que significa ser correcto en el nombre de mi tarea.
Por ejemplo, en este caso de aquí,
Yo diría que un nombre de prueba razonable podría ser prueba aparece un mensaje de victoria
cuando el usuario adivina que coincida con la palabra del día.
Vamos a escribirla.
Perfecto.
Para escribir esta prueba,
primero tenemos que organizar el entorno con todas las condiciones iniciales
que se necesitan para poner nuestra prueba en un buen escenario.
En nuestro caso tenemos que preparar un componente de tablero wordle
con una determinada palabra del día.
Decidí elegir arbitrariamente la palabra del día para los tests.
Ahora, lo que tenemos que asegurarnos
es que ya que nuestro usuario va a hacer una conjetura que coincida
cuando lleguemos a la fase de actuación,
nuestro usuario va a escribir exactamente esta palabra.
Pero genial, así que esto de aquí es suficiente para terminar nuestra fase de arreglo.
Ahora sí, pasemos a la fase act.
En la fase de actuar, vamos a realizar las acciones
que el usuario va a realizar.
Que impulsará una respuesta de nuestra aplicación.
En este caso aquí, nuestro jugador va a escribir una conjetura,
y luego van a enviarlo.
¿Cómo deben presentar su conjetura?
¿Quizás pulsando un botón?
Voy a ir con pueden pulsar enter si teclean una conjetura,
tan pronto como pulsen enter.
El juego nos va a interpretar su conjetura.
Así que, en primer lugar, vamos a identificar la entrada
que el jugador va a interactuar.
Sólo estoy diciendo aquí que estoy encontrando una entrada que toma texto.
Ahora queremos que nuestro jugador a escribir en esa entrada y haga esto,
Con vue/test-utils podemos usar la función such value.
Fíjate cómo estoy haciendo que nuestro reproductor
escriba exactamente la palabra del día como sus invitados.
Por último, queremos que nuestro jugador pulse enter,
para que puedan presentar su conjetura.
Podemos hacer esto utilizando el disparador de vue/test-utils
Y perfecto. Por fin hemos terminado la fase act de nuestro test.
Ahora estamos listos para realizar nuestra aserción.
¿Cómo debería la aplicación responder a esto?
¿Como describe el nombre de la prueba?
Esperamos que aparezca un mensaje de victoria.
Esperemos que un mensaje que diga, has ganado, aparezca en la pantalla.
Para hacer esto, una cosa que podemos hacer es sólo una afirmación sobre todo el texto
que está siendo representado por ese componente.
Podemos hacerlo así.
Ahora, si ejecutamos nuestras pruebas podemos ver que falla inmediatamente.
Y la razón para el fracaso es que en primer lugar,
nos faltaba un puntal requerido del mensaje.
Y además, no podía llamar a la función set value en un DOMWrapper vacío.
Esto significa que que no había ninguna entrada de tipo texto
en la pantalla.
Vamos a corregir estos errores.
Si vamos a nuestro componente,
puedes ver aquí que tenemos un prop de mensaje,
eso es lo que viene del boilerplate.
Cambiemos el nombre a palabra del día.
Y también, asegurémonos de que en app.vue,
también estamos utilizando la palabra del día,
porque acabamos de cambiarlo en nuestro componente.
Por cierto, tiendo a preferir usar el caso kebab para los accesorios,
elige lo que prefieras.
Es sólo una cuestión de estilo.
Vale, por supuesto seguimos fallando
porque todavía no tenemos las entradas de tipo texto.
Así que vamos a conseguir que representa a la pantalla también.
Si ejecuto mi prueba ahora, puedo ver que estoy fallando por una nueva razón.
Esperaba que fueran la sentencia en la pantalla,
pero sólo puedo ver la palabra pruebas.
Y eso es porque estamos renderizando el puntal, justo aquí.
Para conseguir que pase, ¿cuál es la menor cantidad de trabajo necesario?
Podríamos simplemente mostrar siempre el mensaje Has ganado.
Eso es lo que la prueba está buscando, ¿verdad?
Así que vamos a hacer esto.
Si ejecuto mi prueba de nuevo, estoy pasando.
Ahora, usted debe estar pensando que estamos haciendo trampas, ¿verdad?
Después de todo, la prueba nos estaba pidiendo para hacer el mensaje de la victoria.
Cuando el jugador adivina correctamente,
sólo estamos renderizando el mensaje de victoria todo el tiempo.
Puede parecer una tontería,
pero este concepto de hacer lo menos cantidad de trabajo necesario es crítico.
Y nos protege contra dos problemas principales, el exceso de abstracción,
que es complicar demasiado las cosas incluso antes de que necesiten ser complicadas.
Y tener un conjunto de pruebas que no es lo suficientemente robusto.
Y yo diría que en nuestro caso ahora mismo,
estamos sufriendo el segundo escenario.
Nuestro conjunto de pruebas es pequeño. Es sólo una prueba.
Podemos refinarlo más mientras trabajamos en este proyecto.
Pero por el momento siempre renderizando el mensaje de victoria
es suficiente.
Estamos cumpliendo los requisitos de esta tarea.
Estupendo. Ahora que las pruebas están en verde, hagamos una confirmación.
Cada vez que me cuesta pensar cuál debería ser mi mensaje de confirmación,
Me gusta mirar en el nombre de la tarea que acabo de escribir,
porque, la parte central del trabajo que acabo de hacer,
era centrarse en conseguir que estas pruebas pasaran, ¿verdad?
Así que estaba trabajando en las características requeridas
para cumplir los requisitos de esta tarea.
Así que en este caso, podríamos decir que renderizar mensaje de victoria
es una descripción válida de lo que acabamos de trabajar.
Estupendo. En este punto, hemos pasado con éxito por el rojo,
y la fase verde.
Ahora, estamos a punto de entrar la fase del reflector.
Aquí es donde podemos hacer que nuestro código más fácil de entender y mantener.
Hay un par de trucos que podemos utilizar.
Hay este taller increíble de Woody Zuill y Llewellyn Falco,
donde discuten un par de estrategias para refractarios.
He incluido el enlace en la descripción.
Pero en resumen, una de las cosas que buscan, es el desorden.
¿Y qué es el desorden?
El desorden es cualquier cosa en tu código base que es inútil.
Sólo ocupa espacio.
Yo diría, por ejemplo, que,
estos comentarios de aquí que se incluyen
para describir las diferentes fases de prueba no son útiles. Así que vamos a eliminarlos.
Si ejecuto mi tarea de nuevo puedes ver que todavía estamos pasando.
Estupendo. Hagamos un commit, quitar el desorden.
Otra cosa que Woody Zuill y Llewellyn Falco sugieren buscar,
es reducir la complejidad.
Y hay un par de cosas que podemos tener en cuenta
en lo que respecta a la complejidad.
Pero uno de ellos es números mágicos o cadenas mágicas.
Yo diría que este mensaje ¡Has ganado! sería un ejemplo de cadena mágica.
Una de las cosas que podemos hacer aquí es extraer una constante común
que se va a utilizar tanto por nuestra prueba y por nuestra tabla de agua.
Así que vamos a hacer esto.
Voy a hacer un archivo llamado configuración.
En la base del proyecto,
Y esto va a contener esta constante de aquí que puede ser grabada.
También quiero hacer lo mismo para nuestro,
eso no es lo que quiero.
También quiero hacer lo mismo para nuestra palabra wordle.
Vamos a renderizar el mensaje de victoria.
Y perfecto. Ya está. Así que si ejecutamos las pruebas,
podemos ver que todavía estaban pasando.
Así que vamos a hacer un commit y llamar a esa constante de extracción.
Asombroso. Acabamos de terminar nuestro primer bucle TDD.
Hemos escrito un test y lo hemos pasado,
y luego limpiamos nuestro código un poco
para aumentar la mantenibilidad del código base.
Ahora, vamos a empezar el proceso de nuevo.