Es hora de que empecemos a a manejar los controles del reproductor
mediante la determinación de las normas que se aplican a las conjeturas de los jugadores.
Vayamos de arriba a abajo.
Puesto que queremos hacer cumplir que un jugador está limitado a cinco letras,
podemos empezar por tener una prueba en la que, durante la fase de actuación,
nuestro jugador escribe una conjetura que es más de cinco caracteres,
pero en el que los cinco primeros caracteres de esa suposición coinciden con la palabra del día.
Cuando esto ocurre
ya que nuestra aplicación sólo los cinco primeros caracteres,
el jugador debería ver el mensaje de victoria.
Así que escribamos esta aserción.
Si ejecutamos nuestras pruebas, podemos ver que esta nueva prueba está fallando,
porque el mensaje de victoria no se muestra.
En su lugar, estamos viendo el mensaje de derrota.
Bien, vamos a conseguir que pase.
La entrada HTML tiene un atributo llamado maxlength,
que limitaría la cantidad de caracteres que el jugador puede escribir en ese comando de entrada.
Sin embargo, si ejecuto la prueba en este momento, se puede ver que todavía estamos fallando.
La razón de esto es a como funciona vue test utils.
Puedes echar un vistazo aquí
y ver que es a través de la invocación de dicho valor
que emulamos el usuario tecleando su conjetura,
pero esta función evita la protección de maxlength.
Dicho esto, justo después hemos terminado con esta función,
vamos a repasar aún más controles de entrada
que irán más allá de lo que el nativo HTML nativo.
Por esa razón, ir directamente hacia el uso de Vue.js
para manipular la longitud máxima de entrada no es un gran problema en nuestro caso.
Vue ofrece una manera increíble
de controlar y transformar la entrada del usuario sobre la marcha,
y esto es a través de una referencia calculada escribible.
Empiezas definiéndola como lo harías con una referencia normal.
Voy a llamar a esto formattedGuessInProgress.
En una ref. computada
pasarías una llamada de retorno
que devuelve el valor que estás calculando.
Bien, ahora, si quieres hacer una referencia calculada escribible,
lo que tienes que hacer es, en lugar de pasar una sola llamada de retorno,
vamos a pasar un objeto que tiene dos callbacks en su interior,
un getter y un setter.
El getter se comportará como el callback habitual
de una propiedad calculada normal,
pero el emisor tendrá cualquiera que sea el valor bruto
que vamos a recibir de nuestro v-modelo,
y aquí podemos manipular ese valor en bruto de la manera que queramos.
Para nuestra situación en este momento,
lo que necesitamos es limitar el valor en bruto a sólo los cinco primeros caracteres,
y podemos hacerlo así
Estupendo. Si ejecutamos nuestras pruebas, podemos ver que estamos pasando.
Muy bien, vamos a hacer un commit.
Creo que un buen nombre para este commit
podría ser Limitar las adivinanzas de los jugadores a 5 caracteres.
Para nuestra fase de refactorización,
Creo que podemos reducir la complejidad del código base
mediante la extracción de este número 5 en una constante.
¿Qué significa este número 5?
Bueno, es el tamaño de las palabras con las que vamos a jugar,
¿por qué no crear una nueva constante aquí llamada WORD_SIZE.
Y ahora cada vez que escribamos el número 5,
podemos hacer uso de esta constante.
Lo mismo con nuestras pruebas.
Puedo convertir esto en una cadena de plantilla
y luego hacer uso de la constante WORD_SIZE justo aquí.
Estupendo. Nuestras pruebas siguen pasando.
Esta es una gran oportunidad para nosotros para hacer otro commit.
Extraer constante.
Bien, es hora de pasar a nuestra siguiente prueba.
En este caso queremos evitar que el jugador
de la presentación de conjeturas que no son palabras reales.
En este caso, creo que en nuestra fase de actuación,
podríamos tener a nuestro usuario tecleando una conjetura
que no es una palabra real.
Por ejemplo, QWERT.
Y en este caso, porque esta conjetura va a ser rechazada,
el jugador no debe ver el mensaje de victoria
ni el mensaje de derrota porque ninguna conjetura fue realmente presentada.
Así que vamos a copiar esta afirmación de esta prueba anterior aquí
y sólo cambiarlo para tener la palabra clave NOT antes.
Y vamos a hacer lo mismo para el mensaje de derrota.
Si ejecutamos todas nuestras pruebas de nuevo
podemos ver que esta nueva prueba está fallando
porque estamos viendo el mensaje de derrota.
Esto es lo esperado porque nuestra aplicación en este momento,
está aceptando cualquier tipo de conjeturas.
Así que vamos a tratar de limitar esto.
Y una forma de conseguirlo,
es refinando nuestro manejador keydown.enter.
Así que lo que voy a hacer es empezar extrayendo esto en un método.
Y lo que este método va a hacer
es exactamente lo que tenemos aquí.
Estupendo. Así que seguimos fallando y eso está bien.
Ahora lo que voy a hacer es,
antes de asignar el valor de la conjetura en curso
a la conjetura presentada,
Voy a comprobar si la conjetura en curso es una palabra inglesa real.
Y si no lo es voy a volver pronto.
Así que vamos a hacer esto.
Si nuestra colección de palabras en inglés no incluye la conjetura en curso,
hacer un retorno anticipado.
Si ejecutamos nuestras pruebas, podemos ver que hemos vuelto a la fase verde.
Vamos a hacer otro commit.
Evitar que las conjeturas que no son palabras en inglés.
Para nuestra fase de refactorización,
Sinceramente, no veo nada en este momento
que me gustaría refactorizar.
Y eso está bien.
Así que tengamos eso en cuenta
que aunque el bucle TDD es refactorización rojo-verde,
a veces nos encontramos con escenarios como este
en los que acabamos saltándonos una fase.
Así que vamos a nuestra siguiente prueba.
Para hacer cumplir que las conjeturas no distinguen entre mayúsculas y minúsculas,
podríamos hacer que el usuario escriba una conjetura en minúsculas,
pero que de otro modo perfectamente coincide con la palabra del día.
Así que vamos a escribir esta fase del acto.
Si el usuario escribiera la palabra del día ahora mismo,
ganaría el juego, ¿verdad?
Pero lo que voy a hacer es,
Voy a tener el tipo de usuario la palabra del día en minúsculas.
Y todavía queremos que el usuario para ganar el juego,
por lo que debe ver el mensaje de victoria.
Si ejecutamos nuestras pruebas, podemos ver, sin embargo,
que el jugador no ve el mensaje de victoria.
De hecho, no están viendo ningún mensaje
porque su conjetura fue rechazada
debido a no estar en la lista de palabras inglesas que tenemos.
Porque recuerda, nuestra lista de palabras en inglés está toda en mayúsculas.
Bien, hagamos que pase.
Hay diferentes enfoques que podemos hacer aquí,
pero lo que quiero hacer es emular lo que sucede en el juego wordle real.
Y eso es, independientemente si estás escribiendo un carácter en minúscula
o un carácter en mayúsculas,
la salida en el tablero de juego estará siempre en mayúsculas.
Así que podemos hacer lo mismo en nuestra versión de aquí.
Para ello, podemos volver a nuestra escritura calculada ref,
y como parte de la transformación en el setter,
podemos lanzar el valor en bruto a mayúsculas, así.
Así que vamos a ejecutar nuestras pruebas,
y podemos ver que estamos de vuelta a pasar.
Estupendo. Hagamos otra confirmación.
Un buen mensaje de confirmación para este caso sería,
hacer que las conjeturas de los jugadores no distingan entre mayúsculas y minúsculas.
Una vez más, no veo nada aquí que me gustaría refactorizar,
así que creo que estamos bien para pasar a a nuestra siguiente prueba.
Ahora, lo que queremos hacer
es evitar que nuestros jugadores de escribir cualquier cosa que no sea una letra.
Bueno, una buena manera para nosotros para iniciar esta prueba
es por tener nuestra fase de actuar involucrando a nuestro usuario escribiendo una conjetura
que contiene números y caracteres especiales, como este.
Y lo que queremos afirmar en este caso
es que la entrada del jugador contendrá sólo la H, R y T.
Hagamos esto
Bien, si ejecutamos nuestras pruebas, podemos ver que estamos fallando,
porque el número y el carácter especial
han pasado por nuestra entrada.
Muy bien, una vez más,
vamos a refinar nuestro setter en el writable computed ref.
Y para este punto, cada vez que quiero hacer este filtrado más complejo,
Me gusta confiar en RegEx.
Voy a explicar el RegEx que voy a usar aquí,
pero si no estás cómodo con RegEx en general,
Recomiendo encarecidamente visitar regex101.com.
Proporciona un recurso increíble para que conozcas las reglas
y cómo probar tu RegEx.
Pero bien, continuemos.
En este caso, voy a utilizar un RegEx para definir mi objetivo,
y lo reemplazaré por una cadena vacía.
Muy bien, así que permítanme explicar lo que he escrito hasta ahora aquí.
Escribiendo cualquier cosa entre barras
es una de las formas en las que puedes definir RegExes en JavaScript o TypeScript.
Después de la última / podemos pasar opciones de configuración.
"g" significa global, y hace que el RegEx no regrese después de la primera coincidencia.
La bandera "i" significa que nuestro RegEx va a ser insensible a mayúsculas y minúsculas.
Voy a buscar cualquier cosa que no sea una letra,
por lo que una forma en que se puede definir es haciendo este RegEx aquí.
Deja que te lo explique.
Los corchetes me permiten representar un solo carácter
de cualquier conjunto que quiero definir dentro de los corchetes.
El ^ dentro del paréntesis significa no,
por lo tanto, representa un conjunto de todos los caracteres
que no son las letras de la A a la Z.
Añadiendo un + después de este conjunto,
Estoy determinando que estoy buscando una o más apariciones de un carácter
que coincide con este conjunto.
Bien, entonces efectivamente lo que estoy haciendo en la línea 23
es reemplazar cualquier cosa que no sea una letra por una cadena vacía.
Efectivamente la eliminación de ellos del valor en bruto.
Si ejecutamos nuestra prueba podemos ver que estamos pasando.
Estupendo. Hagamos otro commit.
Sólo permitir al jugador escribir letras.
¡Impresionante! Juntos, hemos practicado cómo escribir pruebas para las entradas de los jugadores.
También tuvimos una gran oportunidad para aprovechar Vue writeable computed refs
para permitirnos manipular la entrada del jugador durante un v-model.