1
00:00:00,520 --> 00:00:04,840
Hola, en esta secuencia miraremos
en el marco de prueba SUnit en Pharo,

2
00:00:05,000 --> 00:00:08,720
que nos permiten escribir pruebas unitarias,
como vas a ver

3
00:00:08,880 --> 00:00:13,200
Se utiliza un marco de prueba
para apoyar el desarrollo ágil.

4
00:00:13,360 --> 00:00:16,560
La idea es hacer incremental
desarrollo y prueba

5
00:00:16,720 --> 00:00:18,720
su código regularmente para verificar

6
00:00:18,880 --> 00:00:23,240
que al modificarlo no hemos roto
una propiedad o invariante en el código.

7
00:00:23,400 --> 00:00:25,240
Queremos estar preparados para los cambios.

8
00:00:25,400 --> 00:00:28,160
Escribimos pruebas y luego modificamos nuestros códigos.

9
00:00:28,320 --> 00:00:30,520
entonces podemos volver a ejecutar las pruebas

10
00:00:30,680 --> 00:00:33,680
para verificar que no hemos roto o modificado
todo lo que no deberíamos tener

11
00:00:33,880 --> 00:00:38,520
Las pruebas automáticas son muy importantes.
en el apoyo a este tipo de programación.

12
00:00:38,680 --> 00:00:42,680
El marco SUnit es
Un marco especial para escribir pruebas.

13
00:00:42,840 --> 00:00:46,400
Los hace más fáciles de escribir.
Está en 4 clases, es muy simple.

14
00:00:46,560 --> 00:00:48,960
Fue originalmente
desarrollado por Kent Beck,

15
00:00:49,120 --> 00:00:52,960
y ha inspirado numerosas pruebas
en otros idiomas,

16
00:00:53,120 --> 00:00:55,040
como JUnit, por ejemplo.

17
00:00:55,840 --> 00:00:57,440
Entonces, ¿qué es una prueba?

18
00:00:57,600 --> 00:01:00,080
Hay 3 pasos para escribir una prueba:

19
00:01:00,240 --> 00:01:04,960
Primer paso, creamos un contexto,
por ejemplo, un conjunto vacío.

20
00:01:05,120 --> 00:01:07,480
Paso dos, creo un estímulo,

21
00:01:07,640 --> 00:01:11,960
aquí, así que trato de insertar
un elemento dos veces

22
00:01:12,120 --> 00:01:14,840
en el conjunto que acabo de crear,

23
00:01:15,000 --> 00:01:18,760
y el paso tres,
Probar el resultado que obtengo,

24
00:01:18,920 --> 00:01:23,160
lo que significa que espero hasta
el conjunto solo contiene un elemento.

25
00:01:23,320 --> 00:01:26,960
Un objeto conjunto solo puede contener
un elemento una vez

26
00:01:27,120 --> 00:01:28,680
No puede contenerlo dos veces.

27
00:01:28,840 --> 00:01:32,520
Luego pruebo el resultado,
esperando que la variante no se rompa.

28
00:01:33,120 --> 00:01:35,320
Aquí hay un ejemplo.
Para escribir una prueba ...

29
00:01:35,480 --> 00:01:40,760
Debo escribir una subclase de TestCase.
Llamaré a este "SetTestCase".

30
00:01:40,920 --> 00:01:44,480
Es para probar los sets.
Defino el método, "testAdd".

31
00:01:44,640 --> 00:01:47,240
Todos los métodos comienzan con "prueba".

32
00:01:47,400 --> 00:01:48,960
Luego configuré el contexto,

33
00:01:49,120 --> 00:01:52,200
Creo una instancia
de la clase Establecer, que está vacía,

34
00:01:52,360 --> 00:01:55,840
Agrego 2 elementos,
el mismo elemento dos veces ...

35
00:01:56,000 --> 00:01:59,240
Intento agregar el mismo elemento dos veces

36
00:01:59,400 --> 00:02:03,360
al paquete,
así que 5 dos veces, aquí y aquí.

37
00:02:03,520 --> 00:02:06,000
Entonces lo pruebo, he "verificado" aquí,

38
00:02:06,160 --> 00:02:08,600
Utilizo "assert" para hacer esto,

39
00:02:09,920 --> 00:02:12,840
donde verifico que el tamaño de mi set

40
00:02:13,000 --> 00:02:16,480
es 1, que he tenido éxito
en solo agregar el elemento una vez.

41
00:02:16,640 --> 00:02:19,320
Puedo comenzar la prueba gracias a esto ...

42
00:02:20,720 --> 00:02:24,280
Gracias a esta expresion,
entonces mi prueba revelará

43
00:02:24,440 --> 00:02:28,760
Si la varianza, si "asevera",
La expresión pasada aquí es verdadera.

44
00:02:29,560 --> 00:02:30,880
Todos los métodos que comienzan

45
00:02:31,080 --> 00:02:34,960
con la cadena "prueba" representan una prueba,

46
00:02:35,120 --> 00:02:39,640
y se ejecutará automáticamente
por la herramienta de prueba corredor.

47
00:02:40,440 --> 00:02:44,480
Veremos que todos los resultados,
todas las ejecuciones del método de prueba

48
00:02:44,640 --> 00:02:48,040
producir un resultado
Todos estos resultados se recopilan,

49
00:02:48,200 --> 00:02:52,560
y se recogen en
un objeto de instancia de clase, TestResult.

50
00:02:54,120 --> 00:02:55,760
Te daré otro ejemplo.

51
00:02:55,920 --> 00:02:59,920
En este ejemplo, tenemos el método de prueba,
su nombre comienza con "prueba"

52
00:03:00,080 --> 00:03:03,560
en minúscula, y esto
es el nombre de este método,

53
00:03:03,720 --> 00:03:07,240
"AdjacentRunsWithEquals
AtributosAreMerged "

54
00:03:07,400 --> 00:03:12,960
Entonces tenemos el contexto aquí,
Hemos creado un objeto.

55
00:03:13,120 --> 00:03:14,720
Aquí tenemos un estímulo.

56
00:03:14,880 --> 00:03:18,640
Hemos intentado enviar el mensaje
"addLast times"

57
00:03:18,800 --> 00:03:22,760
a este objeto 3 veces,
la primera vez con

58
00:03:22,920 --> 00:03:26,880
la configuración aquí,
y una segunda vez, la misma configuración

59
00:03:27,040 --> 00:03:28,640
la segunda y la tercera vez

60
00:03:28,800 --> 00:03:31,560
Probamos aquí, es el cheque,

61
00:03:31,720 --> 00:03:35,760
que este elemento es el tamaño 2.
¿Todo bien?

62
00:03:35,960 --> 00:03:40,960
No pudimos agregar el mismo
elemento varias veces de forma adyacente.

63
00:03:41,720 --> 00:03:46,320
En la ejecución de una prueba,
pueden ocurrir varios escenarios.

64
00:03:46,640 --> 00:03:50,720
Un escenario es lo que llamamos
una "falla", lo que significa que

65
00:03:50,880 --> 00:03:53,720
una de las aserciones,
una variante que pensamos que era cierta,

66
00:03:53,880 --> 00:03:56,560
lo que debería ser cierto es falso,
en ese caso

67
00:03:56,720 --> 00:04:01,560
La prueba que contiene "falla"

68
00:04:01,720 --> 00:04:03,600
es un problema anticipado

69
00:04:03,760 --> 00:04:09,240
Esperamos que, potencialmente,
este error estaría presente

70
00:04:09,600 --> 00:04:13,160
Después de eso, un error es una condición
No lo comprobamos.

71
00:04:13,320 --> 00:04:17,240
Es algo que sucede,
una excepción que se plantea,

72
00:04:17,400 --> 00:04:20,480
que no esperábamos
al escribir la prueba.

73
00:04:20,640 --> 00:04:22,480
Son 2 casos muy diferentes.

74
00:04:23,120 --> 00:04:27,640
¿Qué hacemos en una prueba?
cuando queremos verificar

75
00:04:28,480 --> 00:04:32,000
que un poco de código
¿plantea una excepción?

76
00:04:32,160 --> 00:04:36,680
Por ejemplo, quiero verificar
que "establecer nuevo eliminar:1"

77
00:04:36,840 --> 00:04:40,120
este trozo de código,
levantará la excepción "NotFound".

78
00:04:40,280 --> 00:04:42,520
Si hago "Establecer nuevo", es un conjunto vacío.

79
00:04:42,680 --> 00:04:44,640
Estoy tratando de tomar un elemento
de un conjunto vacío.

80
00:04:44,800 --> 00:04:47,600
No tiene sentido
Planteará la excepción "No encontrado"

81
00:04:47,760 --> 00:04:50,800
y en mi prueba utilizo "should raise".

82
00:04:50,960 --> 00:04:53,600
Paso un bloque
y en mi evaluación del bloque,

83
00:04:53,760 --> 00:04:55,240
si se levanta una excepción,

84
00:04:55,400 --> 00:04:59,440
y la excepción es Not Found,
la prueba será verde, estará bien.

85
00:05:00,920 --> 00:05:02,280
También puedo probar lo contrario,

86
00:05:02,440 --> 00:05:04,680
que un poco de código no
plantear una excepción

87
00:05:04,840 --> 00:05:08,440
Aquí uso el método
"Yo no debería criar".

88
00:05:08,600 --> 00:05:12,880
Entonces este bit de código no debería
levante la excepción "NotFound".

89
00:05:14,000 --> 00:05:16,960
Podríamos, al escribir muchas pruebas,

90
00:05:17,120 --> 00:05:19,480
darse cuenta de que hay duplicados

91
00:05:19,640 --> 00:05:21,600
al escribir el contexto de la prueba.

92
00:05:21,920 --> 00:05:23,880
Por ejemplo,
aquí he escrito otra prueba

93
00:05:24,040 --> 00:05:26,120
para los conjuntos, una "prueba de las incidencias".

94
00:05:26,280 --> 00:05:31,800
Vemos que aquí, en el contexto,
Voy a recrear un nuevo set vacío.

95
00:05:31,960 --> 00:05:35,120
Cada vez que escribo una prueba, abro un conjunto,

96
00:05:35,280 --> 00:05:37,880
y cada vez que lo hago
"Establecer nuevo" en el contexto.

97
00:05:38,040 --> 00:05:41,920
Nos gustaría no repetir esta línea.
cada vez en todas nuestras pruebas.

98
00:05:42,080 --> 00:05:45,120
Para no tener que repetirlos,
para poder factorizarlo

99
00:05:45,280 --> 00:05:48,080
en otro lugar, tenemos una solución.

100
00:05:48,240 --> 00:05:52,280
La solución SUnit
es usar el método "setUp"

101
00:05:52,440 --> 00:05:57,160
para factorizar todas las inicializaciones
antes de la ejecución de una prueba.

102
00:05:57,320 --> 00:05:59,680
Entonces, lo que realmente sucede es,

103
00:05:59,840 --> 00:06:02,280
En el momento en que se ejecuta una prueba,
justo antes de una prueba,

104
00:06:02,440 --> 00:06:05,560
por lo tanto, un método que comienza
con la cadena de prueba, se ejecuta,

105
00:06:05,720 --> 00:06:08,760
lanzaremos la ejecución
del método "setUp",

106
00:06:08,960 --> 00:06:11,200
y especifique el contexto.

107
00:06:11,360 --> 00:06:15,320
Durante la prueba usaremos los estímulos

108
00:06:15,480 --> 00:06:17,280
y el cheque, las aserciones,

109
00:06:17,440 --> 00:06:20,200
Y al final
de la ejecución de la prueba

110
00:06:20,360 --> 00:06:22,360
si falla o no,

111
00:06:22,520 --> 00:06:24,880
ejecutaremos el método "tearDown",

112
00:06:25,040 --> 00:06:26,960
que nos permitirá limpiar

113
00:06:27,120 --> 00:06:29,520
todos los recursos que
debe ser lanzado

114
00:06:29,680 --> 00:06:33,360
Si miramos la ejecución
de varios métodos de prueba, es fácil,

115
00:06:33,520 --> 00:06:35,400
tendremos la ejecución de "setUp"

116
00:06:35,560 --> 00:06:37,720
el primer método de prueba ejecutado aquí,

117
00:06:37,880 --> 00:06:41,360
la ejecución de "tearDown" para limpiar,
una nueva ejecución de "setUp"

118
00:06:41,520 --> 00:06:44,720
la ejecución de una nueva prueba,
"tearDown", "setUp",

119
00:06:44,880 --> 00:06:47,760
la ejecución de una prueba
y "tearDown".

120
00:06:47,920 --> 00:06:50,960
Esto nos permite factorizar
implementación del contexto,

121
00:06:51,120 --> 00:06:55,040
y limpiar los recursos en dos métodos,
"setUp" y "tearDown".

122
00:06:56,240 --> 00:06:58,560
Cómo se ve?

123
00:06:58,720 --> 00:07:01,440
En nuestro ejemplo,
si tomo "SetTestCase"

124
00:07:01,600 --> 00:07:04,640
Puedo poner en mi lugar
"definir método setUp",

125
00:07:04,800 --> 00:07:07,320
en el que escribo,
"vacío:= Establecer nuevo",

126
00:07:07,480 --> 00:07:11,840
por lo que "vacío" se convierte en una instancia
variable de "SetTestCase",

127
00:07:12,520 --> 00:07:14,560
y luego en mi prueba,
en mi método de prueba,

128
00:07:14,720 --> 00:07:18,080
Puedo usar directamente
la variable de instancia "vacía",

129
00:07:18,240 --> 00:07:21,880
que se inicializó correctamente,
porque antes de la ejecución

130
00:07:22,040 --> 00:07:26,800
de "testOccurence"
Se ejecutó el método "setUp".

131
00:07:29,680 --> 00:07:33,040
Si miramos a la organización
de las clases

132
00:07:33,200 --> 00:07:37,600
dentro del núcleo de SUnit,
como dije, solo hay 4 clases:

133
00:07:37,760 --> 00:07:41,440
por lo que un caso de prueba,
que no es más ni menos

134
00:07:41,600 --> 00:07:43,560
que una prueba que verifica
que ciertas condiciones,

135
00:07:43,720 --> 00:07:47,000
son ciertas en un contexto dado,
por lo que un caso de prueba tiene

136
00:07:47,960 --> 00:07:50,280
un método "setUp"
un método "teardown"

137
00:07:50,440 --> 00:07:52,840
y luego un grupo de métodos de prueba.

138
00:07:53,000 --> 00:07:57,480
Escribimos un "nuevo" todo el tiempo,
las subclases del caso de prueba.

139
00:07:57,640 --> 00:08:00,520
Estos casos de prueba se combinan

140
00:08:00,680 --> 00:08:05,080
en un "TestSuite"

141
00:08:05,240 --> 00:08:08,560
y podemos lanzar la ejecución
de una suite completa.

142
00:08:08,720 --> 00:08:11,640
Cuando ejecutamos la ejecución
de una suite obtenemos un resultado,

143
00:08:11,800 --> 00:08:16,040
y este resultado es una instancia
de "testResult" aquí,

144
00:08:16,200 --> 00:08:19,120
que nos dice
cuantas pruebas han pasado,

145
00:08:19,280 --> 00:08:22,800
cuantas pruebas se han ejecutado,
cuantos tienen potencialmente

146
00:08:23,480 --> 00:08:26,240
Se encontró con fallas y errores.

147
00:08:27,160 --> 00:08:29,560
También tenemos la noción
de "TestResource"

148
00:08:29,720 --> 00:08:33,960
que nos permite definir
los TestResources para una suite completa.

149
00:08:36,040 --> 00:08:39,760
Un TestCase, como dije,
representa una prueba

150
00:08:39,920 --> 00:08:44,040
Es un método que comienza con "prueba"
definido en una subclase, TestCase.

151
00:08:45,360 --> 00:08:47,360
Un TestSuite es un grupo de pruebas.

152
00:08:47,520 --> 00:08:52,320
Son todos los métodos TestCase.
definido en una o varias clases.

153
00:08:52,480 --> 00:08:56,880
Y un TestResult será un resultado.
de varias ejecuciones de prueba.

154
00:08:58,160 --> 00:09:02,040
Un TestResource
es un objeto que habilitará

155
00:09:02,600 --> 00:09:05,120
la inicialización
de un grupo de recursos,

156
00:09:05,280 --> 00:09:07,520
que son costosas
para inicializar en tiempo normal,

157
00:09:07,680 --> 00:09:10,280
y que solo queremos
inicialice una vez para un grupo de pruebas.

158
00:09:10,440 --> 00:09:14,400
Configuramos un TestResource, inicializamos
Una vez y ejecutar muchas pruebas,

159
00:09:14,560 --> 00:09:17,440
y luego podemos lanzarlo al final.

160
00:09:17,640 --> 00:09:20,320
Lo que deberías saber

161
00:09:20,800 --> 00:09:24,520
es como escribir pruebas.
Escribir pruebas es extremadamente simple,

162
00:09:24,680 --> 00:09:27,480
solo tienes que escribir una subclase
de la clase TestCase,

163
00:09:27,640 --> 00:09:31,240
definir los métodos en él
que comienzan con "prueba",

164
00:09:31,400 --> 00:09:33,440
y luego configurar un contexto dentro de él,

165
00:09:33,600 --> 00:09:36,960
envía los estímulos y prueba
Las afirmaciones, que deberían ser ciertas.

166
00:09:37,800 --> 00:09:39,720
Reutilizamos los contextos,

167
00:09:39,880 --> 00:09:42,240
para que pueda reutilizar los contextos
a través de varios métodos de prueba,

168
00:09:42,400 --> 00:09:45,640
al factorizarlos
en un método SetUp, por ejemplo.

169
00:09:47,000 --> 00:09:52,080
En resumen, en esta secuencia
hemos visto el marco de prueba SUnit,

170
00:09:52,240 --> 00:09:54,360
que es extremadamente simple de usar,

171
00:09:54,520 --> 00:09:57,560
y extremadamente eficiente
para configurar desarrollos ágiles.

172
00:09:57,720 --> 00:10:01,520
Les recomiendo encarecidamente que los usen,
Definir pruebas es muy fácil.

173
00:10:01,680 --> 00:10:04,840
La gran ventaja es que cuando
has creado una prueba

174
00:10:05,000 --> 00:10:10,400
Puedes ejecutarlo un millón de veces.
y es muy útil para asegurarte

175
00:10:10,560 --> 00:10:13,360
que su código sigue funcionando,
incluso si has cambiado cosas,

176
00:10:13,520 --> 00:10:16,640
y se han producido efectos de borde,
puedes detectarlos

177
00:10:16,800 --> 00:10:20,720
si has estado actualizado
suficiente en las pruebas que has escrito.

178
00:10:20,880 --> 00:10:25,320
Puedes ir más allá creando pruebas.
mediante el uso de marcos de punto,

179
00:10:25,480 --> 00:10:28,640
típicamente marcos falsos
como BabyMock, etc ...

180
00:10:28,840 --> 00:10:33,440
tener diferente
estilos de prueba y prueba de escritura.

181
00:10:34,480 --> 00:10:38,720
Lo invito a usar y crear
muchas pruebas en tu programa