﻿1
00:00:05,020 --> 00:00:07,200
Antes de empezar a escribir nuestras pruebas,

2
00:00:07,225 --> 00:00:10,967
Quiero que hagamos una rápida
a nuestras configuraciones.

3
00:00:11,267 --> 00:00:15,733
Vitest nos permite hacer uso
de sus funciones como describir,

4
00:00:15,833 --> 00:00:21,083
esperar, y sin tener que
que importarlas nosotros mismos,

5
00:00:21,100 --> 00:00:26,093
cada vez que los necesitemos.
Τo do this, we need to enable globals.

6
00:00:26,653 --> 00:00:30,267
Podemos hacerlo yendo
a nuestro vitest.config

7
00:00:30,600 --> 00:00:34,480
y poniendo la bandera
de globals a true, así

8
00:00:39,205 --> 00:00:41,508
Finalmente, ya que estábamos usando typescript

9
00:00:41,533 --> 00:00:47,100
deberíamos hacer saber al intérprete
que vitest globals está disponible.

10
00:00:47,533 --> 00:00:51,800
Para ello, tenemos que ir
a nuestro tsconfig.vitest.json,

11
00:00:51,926 --> 00:00:57,090
y añadir un tipo extra vitest/globals.

12
00:00:59,650 --> 00:01:05,467
Perfecto. Ahora podemos volver a nuestra prueba
y borrar esta sentencia import.

13
00:01:06,553 --> 00:01:07,930
Si intento ejecutarlos

14
00:01:08,406 --> 00:01:10,903
puedes ver que siguen pasando.

15
00:01:14,910 --> 00:01:17,967
Estupendo. Deberíamos estar listos
para hacer un commit ahora.

16
00:01:18,883 --> 00:01:22,867
Ahora, voy a llamar a este commit,
usar vitest globals.

17
00:01:25,320 --> 00:01:28,300
Ahora vamos a empezar a escribir nuestra primera prueba.

18
00:01:28,747 --> 00:01:30,550
Como cubrimos en la primera lección,

19
00:01:30,575 --> 00:01:33,196
un principio clave detrás del
desarrollo basado en pruebas

20
00:01:33,221 --> 00:01:36,021
es el rojo verde
refactorizar el bucle de desarrollo.

21
00:01:36,767 --> 00:01:38,567
Esto significa que el primer paso

22
00:01:38,600 --> 00:01:41,387
tomará para conseguir
nuestro juego worldle implementado

23
00:01:41,413 --> 00:01:44,586
es escribir la primera prueba
con nuestros requisitos

24
00:01:44,600 --> 00:01:46,713
que queremos que cumpla nuestra aplicación.

25
00:01:47,367 --> 00:01:49,433
Ya que estamos haciendo un clon del mundo,

26
00:01:49,458 --> 00:01:52,033
Yo diría que un buen primer requisito

27
00:01:52,058 --> 00:01:57,370
podría ser que si un usuario hace una conjetura
que coincida con la palabra del día,

28
00:01:57,395 --> 00:02:00,167
deberíamos mostrarle un mensaje de victoria.

29
00:02:00,446 --> 00:02:01,566
Hagamos esto.

30
00:02:01,712 --> 00:02:03,917
Cuando estoy pensando en un nombre para una prueba,

31
00:02:03,942 --> 00:02:06,333
Me gusta pensar en un nombre que,

32
00:02:06,358 --> 00:02:09,200
incluso alguien que es un juez
puede entender.

33
00:02:10,066 --> 00:02:14,833
Además, trato de evitar
usar palabras como correcto e incorrecto,

34
00:02:15,200 --> 00:02:18,667
porque por sí mismas,
no tienen mucho significado.

35
00:02:18,692 --> 00:02:23,767
Me gusta explicar lo que significa
ser correcto en el nombre de mi tarea.

36
00:02:24,833 --> 00:02:27,100
Por ejemplo, en este caso de aquí,

37
00:02:27,125 --> 00:02:33,133
Yo diría que un nombre de prueba razonable
podría ser prueba aparece un mensaje de victoria

38
00:02:33,158 --> 00:02:37,200
cuando el usuario adivina
que coincida con la palabra del día.

39
00:02:37,440 --> 00:02:38,610
Vamos a escribirla.

40
00:02:44,930 --> 00:02:45,967
Perfecto.

41
00:02:46,953 --> 00:02:48,300
Para escribir esta prueba,

42
00:02:48,325 --> 00:02:52,483
primero tenemos que organizar el entorno
con todas las condiciones iniciales

43
00:02:52,500 --> 00:02:55,533
que se necesitan
para poner nuestra prueba en un buen escenario.

44
00:02:56,033 --> 00:03:01,067
En nuestro caso
tenemos que preparar un componente de tablero wordle

45
00:03:01,460 --> 00:03:04,467
con una determinada palabra del día.

46
00:03:04,667 --> 00:03:09,467
Decidí elegir arbitrariamente
la palabra del día para los tests.

47
00:03:09,673 --> 00:03:11,708
Ahora, lo que tenemos que asegurarnos

48
00:03:11,733 --> 00:03:15,467
es que ya que nuestro usuario
va a hacer una conjetura que coincida

49
00:03:16,067 --> 00:03:18,267
cuando lleguemos a la fase de actuación,

50
00:03:18,300 --> 00:03:22,630
nuestro usuario va a escribir
exactamente esta palabra.

51
00:03:22,655 --> 00:03:27,567
Pero genial, así que esto de aquí es suficiente
para terminar nuestra fase de arreglo.

52
00:03:28,767 --> 00:03:30,967
Ahora sí, pasemos a la fase act.

53
00:03:31,000 --> 00:03:35,173
En la fase de actuar,
vamos a realizar las acciones

54
00:03:35,198 --> 00:03:37,087
que el usuario va a realizar.

55
00:03:37,112 --> 00:03:40,200
Que impulsará una respuesta
de nuestra aplicación.

56
00:03:40,333 --> 00:03:45,033
En este caso aquí,
nuestro jugador va a escribir una conjetura,

57
00:03:45,213 --> 00:03:47,133
y luego van a enviarlo.

58
00:03:48,133 --> 00:03:49,717
¿Cómo deben presentar su conjetura?

59
00:03:49,733 --> 00:03:52,203
¿Quizás pulsando un botón?

60
00:03:52,333 --> 00:03:56,933
Voy a ir con
pueden pulsar enter si teclean una conjetura,

61
00:03:56,933 --> 00:03:58,433
tan pronto como pulsen enter.

62
00:03:58,540 --> 00:04:02,333
El juego nos va a interpretar
su conjetura.

63
00:04:02,358 --> 00:04:06,100
Así que, en primer lugar, vamos a identificar la entrada

64
00:04:06,125 --> 00:04:08,083
que el jugador
va a interactuar.

65
00:04:08,133 --> 00:04:12,967
Sólo estoy diciendo aquí que estoy encontrando
una entrada que toma texto.

66
00:04:13,467 --> 00:04:17,856
Ahora queremos que nuestro jugador a escribir
en esa entrada y haga esto,

67
00:04:17,881 --> 00:04:21,529
Con vue/test-utils
podemos usar la función such value.

68
00:04:22,267 --> 00:04:24,033
Fíjate cómo estoy haciendo que nuestro reproductor

69
00:04:24,058 --> 00:04:26,900
escriba exactamente
la palabra del día como sus invitados.

70
00:04:27,200 --> 00:04:29,967
Por último, queremos que nuestro jugador
pulse enter,

71
00:04:29,992 --> 00:04:32,067
para que puedan presentar su conjetura.

72
00:04:32,833 --> 00:04:36,533
Podemos hacer esto utilizando el disparador
de vue/test-utils

73
00:04:38,107 --> 00:04:43,267
Y perfecto. Por fin hemos
terminado la fase act de nuestro test.

74
00:04:43,966 --> 00:04:47,400
Ahora estamos listos para realizar nuestra aserción.

75
00:04:48,013 --> 00:04:51,167
¿Cómo debería la aplicación
responder a esto?

76
00:04:51,200 --> 00:04:53,333
¿Como describe el nombre de la prueba?

77
00:04:53,358 --> 00:04:55,633
Esperamos que aparezca un mensaje de victoria.

78
00:04:55,658 --> 00:05:00,167
Esperemos que un mensaje que diga,
has ganado, aparezca en la pantalla.

79
00:05:00,270 --> 00:05:04,936
Para hacer esto, una cosa que podemos hacer
es sólo una afirmación sobre todo el texto

80
00:05:04,961 --> 00:05:07,067
que está siendo representado por ese componente.

81
00:05:07,133 --> 00:05:08,700
Podemos hacerlo así.

82
00:05:13,620 --> 00:05:19,033
Ahora, si ejecutamos nuestras pruebas
podemos ver que falla inmediatamente.

83
00:05:21,343 --> 00:05:24,800
Y la razón
para el fracaso es que en primer lugar,

84
00:05:24,867 --> 00:05:27,570
nos faltaba
un puntal requerido del mensaje.

85
00:05:28,676 --> 00:05:34,500
Y además, no podía llamar a la función set
value en un DOMWrapper vacío.

86
00:05:34,700 --> 00:05:38,133
Esto significa que
que no había ninguna entrada de tipo texto

87
00:05:38,166 --> 00:05:40,003
en la pantalla.

88
00:05:40,613 --> 00:05:42,293
Vamos a corregir estos errores.

89
00:05:43,690 --> 00:05:45,533
Si vamos a nuestro componente,

90
00:05:46,807 --> 00:05:49,573
puedes ver aquí
que tenemos un prop de mensaje,

91
00:05:49,598 --> 00:05:51,727
eso es lo que viene del boilerplate.

92
00:05:51,987 --> 00:05:55,867
Cambiemos el nombre a palabra del día.

93
00:05:59,650 --> 00:06:03,300
Y también, asegurémonos de que en app.vue,

94
00:06:03,400 --> 00:06:07,063
también estamos utilizando
la palabra del día,

95
00:06:07,227 --> 00:06:10,667
porque acabamos de cambiarlo
en nuestro componente.

96
00:06:11,500 --> 00:06:14,923
Por cierto, tiendo a preferir
usar el caso kebab para los accesorios,

97
00:06:15,467 --> 00:06:16,883
elige lo que prefieras.

98
00:06:16,908 --> 00:06:18,600
Es sólo una cuestión de estilo.

99
00:06:20,542 --> 00:06:22,600
Vale, por supuesto seguimos fallando

100
00:06:22,633 --> 00:06:26,267
porque todavía no tenemos
las entradas de tipo texto.

101
00:06:26,767 --> 00:06:31,600
Así que vamos a conseguir que representa
a la pantalla también.

102
00:06:34,603 --> 00:06:39,867
Si ejecuto mi prueba ahora, puedo ver
que estoy fallando por una nueva razón.

103
00:06:40,339 --> 00:06:45,567
Esperaba que fueran la sentencia
en la pantalla,

104
00:06:45,567 --> 00:06:48,437
pero sólo puedo ver la palabra pruebas.

105
00:06:48,467 --> 00:06:51,203
Y eso es porque
estamos renderizando el puntal, justo aquí.

106
00:06:52,717 --> 00:06:56,533
Para conseguir que pase, ¿cuál es la menor
cantidad de trabajo necesario?

107
00:06:59,302 --> 00:07:04,767
Podríamos simplemente mostrar siempre
el mensaje Has ganado.

108
00:07:05,646 --> 00:07:07,710
Eso es lo que la prueba
está buscando, ¿verdad?

109
00:07:07,735 --> 00:07:09,233
Así que vamos a hacer esto.

110
00:07:09,439 --> 00:07:12,567
Si ejecuto mi prueba de nuevo, estoy pasando.

111
00:07:12,967 --> 00:07:16,600
Ahora, usted debe estar pensando
que estamos haciendo trampas, ¿verdad?

112
00:07:16,667 --> 00:07:20,900
Después de todo, la prueba nos estaba pidiendo
para hacer el mensaje de la victoria.

113
00:07:21,000 --> 00:07:23,633
Cuando el jugador adivina correctamente,

114
00:07:24,233 --> 00:07:27,533
sólo estamos renderizando
el mensaje de victoria todo el tiempo.

115
00:07:28,193 --> 00:07:29,690
Puede parecer una tontería,

116
00:07:29,800 --> 00:07:35,157
pero este concepto de hacer lo menos
cantidad de trabajo necesario es crítico.

117
00:07:35,182 --> 00:07:39,667
Y nos protege contra
dos problemas principales, el exceso de abstracción,

118
00:07:39,700 --> 00:07:45,500
que es complicar demasiado las cosas
incluso antes de que necesiten ser complicadas.

119
00:07:45,867 --> 00:07:49,667
Y tener un conjunto de pruebas
que no es lo suficientemente robusto.

120
00:07:50,367 --> 00:07:53,050
Y yo diría
que en nuestro caso ahora mismo,

121
00:07:53,086 --> 00:07:55,733
estamos sufriendo el segundo escenario.

122
00:07:57,226 --> 00:08:01,453
Nuestro conjunto de pruebas es pequeño.
Es sólo una prueba.

123
00:08:01,478 --> 00:08:04,823
Podemos refinarlo más
mientras trabajamos en este proyecto.

124
00:08:05,220 --> 00:08:09,333
Pero por el momento
siempre renderizando el mensaje de victoria

125
00:08:09,400 --> 00:08:11,023
es suficiente.

126
00:08:11,033 --> 00:08:14,700
Estamos cumpliendo
los requisitos de esta tarea.

127
00:08:15,199 --> 00:08:18,700
Estupendo. Ahora que las pruebas están en verde,
hagamos una confirmación.

128
00:08:20,090 --> 00:08:24,767
Cada vez que me cuesta pensar
cuál debería ser mi mensaje de confirmación,

129
00:08:25,033 --> 00:08:28,967
Me gusta mirar en el nombre
de la tarea que acabo de escribir,

130
00:08:29,386 --> 00:08:34,177
porque, la parte central
del trabajo que acabo de hacer,

131
00:08:34,400 --> 00:08:37,730
era centrarse
en conseguir que estas pruebas pasaran, ¿verdad?

132
00:08:37,833 --> 00:08:42,067
Así que estaba trabajando en las características requeridas

133
00:08:42,100 --> 00:08:44,270
para cumplir los requisitos de esta tarea.

134
00:08:45,017 --> 00:08:49,600
Así que en este caso, podríamos decir
que renderizar mensaje de victoria

135
00:08:51,957 --> 00:08:55,500
es una descripción válida
de lo que acabamos de trabajar.

136
00:08:58,097 --> 00:09:02,400
Estupendo. En este punto,
hemos pasado con éxito por el rojo,

137
00:09:02,467 --> 00:09:03,803
y la fase verde.

138
00:09:03,833 --> 00:09:06,833
Ahora, estamos a punto de entrar
la fase del reflector.

139
00:09:07,046 --> 00:09:12,467
Aquí es donde podemos hacer que nuestro código
más fácil de entender y mantener.

140
00:09:13,227 --> 00:09:15,733
Hay un par de trucos
que podemos utilizar.

141
00:09:16,400 --> 00:09:22,180
Hay este taller increíble
de Woody Zuill y Llewellyn Falco,

142
00:09:22,205 --> 00:09:25,333
donde discuten un par
de estrategias para refractarios.

143
00:09:25,358 --> 00:09:27,433
He incluido el enlace en la descripción.

144
00:09:27,666 --> 00:09:32,700
Pero en resumen, una de las cosas
que buscan, es el desorden.

145
00:09:33,133 --> 00:09:34,606
¿Y qué es el desorden?

146
00:09:34,633 --> 00:09:38,530
El desorden es cualquier cosa
en tu código base que es inútil.

147
00:09:38,555 --> 00:09:40,300
Sólo ocupa espacio.

148
00:09:40,486 --> 00:09:43,023
Yo diría, por ejemplo, que,

149
00:09:43,100 --> 00:09:45,073
estos comentarios de aquí
que se incluyen

150
00:09:45,098 --> 00:09:50,333
para describir las diferentes fases de prueba
no son útiles. Así que vamos a eliminarlos.

151
00:09:52,767 --> 00:09:56,633
Si ejecuto mi tarea de nuevo
puedes ver que todavía estamos pasando.

152
00:09:56,658 --> 00:10:00,058
Estupendo. Hagamos un commit,
quitar el desorden.

153
00:10:01,172 --> 00:10:05,967
Otra cosa que Woody Zuill
y Llewellyn Falco sugieren buscar,

154
00:10:06,000 --> 00:10:08,305
es reducir la complejidad.

155
00:10:08,600 --> 00:10:12,567
Y hay un par de cosas
que podemos tener en cuenta

156
00:10:12,592 --> 00:10:14,113
en lo que respecta a la complejidad.

157
00:10:14,133 --> 00:10:19,400
Pero uno de ellos es números mágicos
o cadenas mágicas.

158
00:10:19,553 --> 00:10:25,300
Yo diría que este mensaje ¡Has ganado!
sería un ejemplo de cadena mágica.

159
00:10:26,643 --> 00:10:31,250
Una de las cosas que podemos hacer aquí
es extraer una constante común

160
00:10:31,275 --> 00:10:36,400
que se va a utilizar
tanto por nuestra prueba y por nuestra tabla de agua.

161
00:10:37,486 --> 00:10:39,000
Así que vamos a hacer esto.

162
00:10:43,297 --> 00:10:46,500
Voy a hacer un archivo llamado configuración.

163
00:10:48,597 --> 00:10:50,300
En la base del proyecto,

164
00:10:50,540 --> 00:10:54,340
Y esto va a contener
esta constante de aquí que puede ser grabada.

165
00:10:57,747 --> 00:11:00,443
También quiero hacer lo mismo para nuestro,

166
00:11:01,783 --> 00:11:03,433
eso no es lo que quiero.

167
00:11:03,767 --> 00:11:06,633
También quiero hacer lo mismo
para nuestra palabra wordle.

168
00:11:06,807 --> 00:11:12,500
Vamos a
renderizar el mensaje de victoria.

169
00:11:15,403 --> 00:11:19,067
Y perfecto. Ya está.
Así que si ejecutamos las pruebas,

170
00:11:19,599 --> 00:11:22,000
podemos ver que todavía estaban pasando.

171
00:11:22,803 --> 00:11:26,700
Así que vamos a hacer un commit
y llamar a esa constante de extracción.

172
00:11:29,017 --> 00:11:32,433
Asombroso.
Acabamos de terminar nuestro primer bucle TDD.

173
00:11:32,620 --> 00:11:35,067
Hemos escrito un test y lo hemos pasado,

174
00:11:35,100 --> 00:11:37,467
y luego limpiamos
nuestro código un poco

175
00:11:37,533 --> 00:11:40,100
para aumentar la mantenibilidad
del código base.

176
00:11:40,513 --> 00:11:43,533
Ahora, vamos a empezar el proceso
de nuevo.


