Para garantizar que los controles sean retirados del reproductor
en cuanto termine el juego, opté por crear dos nuevas pruebas,
una que aseguraría que el jugador perdería el control
después de haber hecho una serie de errores,
es decir, no han conseguido ganar el juego,
y otra que aseguraría que el jugador pierde el control
una vez que gane el juego.
Ambas pruebas fueron escritas dentro del bloque de descripción de la entrada del jugador.
Para el caso de perder el juego
Acabo de hacer que el jugador haga seis errores seguidos
y luego afirmo que la entrada del jugador tiene el atributo disabled.
Del mismo modo, para el caso de que el jugador gane el juego,
el jugador acertará,
es decir, su suposición va a contendrá la palabra del día,
y al igual que en la prueba anterior,
la entrada también debe tener el atributo disabled.
Para que esta prueba pase,
He definido un prop opcional en la entrada del jugador.
Así que puedes ver aquí que estoy definiendo desactivado
como una propiedad opcional de tipo booleano,
y si el usuario no me proporciona esta prop,
será por defecto el valor falso.
Esta prop se utiliza directamente en la entrada nativa.
Así que está inmediatamente ligada al atributo HTML disabled.
Este accesorio está siendo utilizado por el wordleboard.
Puedes ver aquí que el accesorio desactivado
sólo utiliza cualquier valor contenido
dentro de nuestra propiedad calculada isGameOver.
Así que tan pronto como el juego termine la propiedad disabled se convierte en true.
De lo contrario, la propiedad desactivada es falsa.
Para este trabajo, he hecho un commit llamado disableControls
si el juego ha terminado.
Y como puedes ver todas las pruebas siguen pasando.
En cuanto a la representación todo el tablero con conjeturas vacías
al comienzo del juego,
Consideré fuertemente no escribir ninguna prueba adicional para esto,
ya que primero pensé que esto sería sólo una preferencia estilística
en lugar de un verdadero operativo de la aplicación.
Pero al pensar un poco más sobre esto cambié de opinión y llegué a la conclusión
que el tablero siempre debe mostrar exactamente cuántas conjeturas puede hacer el usuario
es un requisito del juego.
Pero honestamente, siéntete libre de estar en desacuerdo conmigo.
Sólo ten en cuenta que la idea
es que deberíamos estar probando el comportamiento y los objetivos,
y esta línea puede ser un poco borrosa a veces.
Así que aquí están las pruebas que escribí
para hacer cumplir que siempre habrá seis conjeturas
presentes durante todo el juego.
Así que hice un bloque bloque descriptivo para esto,
y me aseguro de que habrá exactamente seis conjeturas vistas
al comienzo del juego.
Y esto también sigue siendo cierto si el jugador gana el juego,
y sigue siendo cierto si el jugador pierde el juego.
Así que son tres pruebas diferentes,
todas responsables de asegurar
que el número de conjeturas vistas en la página no cambie.
Para que pasen,
He optado por crear un grupo adicional de elementos de la lista.
Y puedes ver aquí
que sólo estoy haciendo una serie de conjeturas vacías
bajo la vista de la conjetura de entrada.
Y para calcular el número de conjeturas vacías,
Utilizo esta propiedad calculada aquí
que se basa en lo que es la MAX_GUESSES_COUNT
a la que tiene derecho el jugador,
y cuántos aciertos han presentado hasta ahora.
Por supuesto que una vez terminado el juego
la conjetura de entrada ya no será accesible,
así que también necesito tenerlo en cuenta aquí.
Un inconveniente de la forma Escribí estas pruebas aquí
es que estoy haciendo cumplir una determinada cantidad de componentes guess-view en concreto.
Por lo tanto, en cierto modo,
las pruebas que escribí aquí están probando parte de la implementación.
Escribir tests no es una ciencia exacta,
y sigue siendo algo que tú y yo deberíamos esforzarnos por mejorar cada día.
Si tienes una sugerencia mejor
sobre cómo deberíamos haber escrito esta prueba de aquí,
por favor, no dudes en contactar con nosotros.
Me encantaría escuchar tus ideas.
¡Impresionante! Con esto, nos hemos asegurado
nuestros jugadores podrán ver todas las adivinanzas que han hecho,
y cuántas suposiciones pueden realizar en el futuro.
Y no sólo eso,
sino que también hemos evitado con éxito que nuestros jugadores adivinaran
una vez que el juego ha terminado,
que era una gran manera de explorar cómo desactivar entradas con vue
y cómo probar ese comportamiento a través de vitest con vue test utils.