Hola, en esta secuencia miraremos en el marco de prueba SUnit en Pharo,
que nos permiten escribir pruebas unitarias, como vas a ver
Se utiliza un marco de prueba para apoyar el desarrollo ágil.
La idea es hacer incremental desarrollo y prueba
su código regularmente para verificar
que al modificarlo no hemos roto una propiedad o invariante en el código.
Queremos estar preparados para los cambios.
Escribimos pruebas y luego modificamos nuestros códigos.
entonces podemos volver a ejecutar las pruebas
para verificar que no hemos roto o modificado todo lo que no deberíamos tener
Las pruebas automáticas son muy importantes. en el apoyo a este tipo de programación.
El marco SUnit es Un marco especial para escribir pruebas.
Los hace más fáciles de escribir. Está en 4 clases, es muy simple.
Fue originalmente desarrollado por Kent Beck,
y ha inspirado numerosas pruebas en otros idiomas,
como JUnit, por ejemplo.
Entonces, ¿qué es una prueba?
Hay 3 pasos para escribir una prueba:
Primer paso, creamos un contexto, por ejemplo, un conjunto vacío.
Paso dos, creo un estímulo,
aquí, así que trato de insertar un elemento dos veces
en el conjunto que acabo de crear,
y el paso tres, Probar el resultado que obtengo,
lo que significa que espero hasta el conjunto solo contiene un elemento.
Un objeto conjunto solo puede contener un elemento una vez
No puede contenerlo dos veces.
Luego pruebo el resultado, esperando que la variante no se rompa.
Aquí hay un ejemplo. Para escribir una prueba ...
Debo escribir una subclase de TestCase. Llamaré a este "SetTestCase".
Es para probar los sets. Defino el método, "testAdd".
Todos los métodos comienzan con "prueba".
Luego configuré el contexto,
Creo una instancia de la clase Establecer, que está vacía,
Agrego 2 elementos, el mismo elemento dos veces ...
Intento agregar el mismo elemento dos veces
al paquete, así que 5 dos veces, aquí y aquí.
Entonces lo pruebo, he "verificado" aquí,
Utilizo "assert" para hacer esto,
donde verifico que el tamaño de mi set
es 1, que he tenido éxito en solo agregar el elemento una vez.
Puedo comenzar la prueba gracias a esto ...
Gracias a esta expresion, entonces mi prueba revelará
Si la varianza, si "asevera", La expresión pasada aquí es verdadera.
Todos los métodos que comienzan
con la cadena "prueba" representan una prueba,
y se ejecutará automáticamente por la herramienta de prueba corredor.
Veremos que todos los resultados, todas las ejecuciones del método de prueba
producir un resultado Todos estos resultados se recopilan,
y se recogen en un objeto de instancia de clase, TestResult.
Te daré otro ejemplo.
En este ejemplo, tenemos el método de prueba, su nombre comienza con "prueba"
en minúscula, y esto es el nombre de este método,
"AdjacentRunsWithEquals AtributosAreMerged "
Entonces tenemos el contexto aquí, Hemos creado un objeto.
Aquí tenemos un estímulo.
Hemos intentado enviar el mensaje "addLast times"
a este objeto 3 veces, la primera vez con
la configuración aquí, y una segunda vez, la misma configuración
la segunda y la tercera vez
Probamos aquí, es el cheque,
que este elemento es el tamaño 2. ¿Todo bien?
No pudimos agregar el mismo elemento varias veces de forma adyacente.
En la ejecución de una prueba, pueden ocurrir varios escenarios.
Un escenario es lo que llamamos una "falla", lo que significa que
una de las aserciones, una variante que pensamos que era cierta,
lo que debería ser cierto es falso, en ese caso
La prueba que contiene "falla"
es un problema anticipado
Esperamos que, potencialmente, este error estaría presente
Después de eso, un error es una condición No lo comprobamos.
Es algo que sucede, una excepción que se plantea,
que no esperábamos al escribir la prueba.
Son 2 casos muy diferentes.
¿Qué hacemos en una prueba? cuando queremos verificar
que un poco de código ¿plantea una excepción?
Por ejemplo, quiero verificar que "establecer nuevo eliminar:1"
este trozo de código, levantará la excepción "NotFound".
Si hago "Establecer nuevo", es un conjunto vacío.
Estoy tratando de tomar un elemento de un conjunto vacío.
No tiene sentido Planteará la excepción "No encontrado"
y en mi prueba utilizo "should raise".
Paso un bloque y en mi evaluación del bloque,
si se levanta una excepción,
y la excepción es Not Found, la prueba será verde, estará bien.
También puedo probar lo contrario,
que un poco de código no plantear una excepción
Aquí uso el método "Yo no debería criar".
Entonces este bit de código no debería levante la excepción "NotFound".
Podríamos, al escribir muchas pruebas,
darse cuenta de que hay duplicados
al escribir el contexto de la prueba.
Por ejemplo, aquí he escrito otra prueba
para los conjuntos, una "prueba de las incidencias".
Vemos que aquí, en el contexto, Voy a recrear un nuevo set vacío.
Cada vez que escribo una prueba, abro un conjunto,
y cada vez que lo hago "Establecer nuevo" en el contexto.
Nos gustaría no repetir esta línea. cada vez en todas nuestras pruebas.
Para no tener que repetirlos, para poder factorizarlo
en otro lugar, tenemos una solución.
La solución SUnit es usar el método "setUp"
para factorizar todas las inicializaciones antes de la ejecución de una prueba.
Entonces, lo que realmente sucede es,
En el momento en que se ejecuta una prueba, justo antes de una prueba,
por lo tanto, un método que comienza con la cadena de prueba, se ejecuta,
lanzaremos la ejecución del método "setUp",
y especifique el contexto.
Durante la prueba usaremos los estímulos
y el cheque, las aserciones,
Y al final de la ejecución de la prueba
si falla o no,
ejecutaremos el método "tearDown",
que nos permitirá limpiar
todos los recursos que debe ser lanzado
Si miramos la ejecución de varios métodos de prueba, es fácil,
tendremos la ejecución de "setUp"
el primer método de prueba ejecutado aquí,
la ejecución de "tearDown" para limpiar, una nueva ejecución de "setUp"
la ejecución de una nueva prueba, "tearDown", "setUp",
la ejecución de una prueba y "tearDown".
Esto nos permite factorizar implementación del contexto,
y limpiar los recursos en dos métodos, "setUp" y "tearDown".
Cómo se ve?
En nuestro ejemplo, si tomo "SetTestCase"
Puedo poner en mi lugar "definir método setUp",
en el que escribo, "vacío:= Establecer nuevo",
por lo que "vacío" se convierte en una instancia variable de "SetTestCase",
y luego en mi prueba, en mi método de prueba,
Puedo usar directamente la variable de instancia "vacía",
que se inicializó correctamente, porque antes de la ejecución
de "testOccurence" Se ejecutó el método "setUp".
Si miramos a la organización de las clases
dentro del núcleo de SUnit, como dije, solo hay 4 clases:
por lo que un caso de prueba, que no es más ni menos
que una prueba que verifica que ciertas condiciones,
son ciertas en un contexto dado, por lo que un caso de prueba tiene
un método "setUp" un método "teardown"
y luego un grupo de métodos de prueba.
Escribimos un "nuevo" todo el tiempo, las subclases del caso de prueba.
Estos casos de prueba se combinan
en un "TestSuite"
y podemos lanzar la ejecución de una suite completa.
Cuando ejecutamos la ejecución de una suite obtenemos un resultado,
y este resultado es una instancia de "testResult" aquí,
que nos dice cuantas pruebas han pasado,
cuantas pruebas se han ejecutado, cuantos tienen potencialmente
Se encontró con fallas y errores.
También tenemos la noción de "TestResource"
que nos permite definir los TestResources para una suite completa.
Un TestCase, como dije, representa una prueba
Es un método que comienza con "prueba" definido en una subclase, TestCase.
Un TestSuite es un grupo de pruebas.
Son todos los métodos TestCase. definido en una o varias clases.
Y un TestResult será un resultado. de varias ejecuciones de prueba.
Un TestResource es un objeto que habilitará
la inicialización de un grupo de recursos,
que son costosas para inicializar en tiempo normal,
y que solo queremos inicialice una vez para un grupo de pruebas.
Configuramos un TestResource, inicializamos Una vez y ejecutar muchas pruebas,
y luego podemos lanzarlo al final.
Lo que deberías saber
es como escribir pruebas. Escribir pruebas es extremadamente simple,
solo tienes que escribir una subclase de la clase TestCase,
definir los métodos en él que comienzan con "prueba",
y luego configurar un contexto dentro de él,
envía los estímulos y prueba Las afirmaciones, que deberían ser ciertas.
Reutilizamos los contextos,
para que pueda reutilizar los contextos a través de varios métodos de prueba,
al factorizarlos en un método SetUp, por ejemplo.
En resumen, en esta secuencia hemos visto el marco de prueba SUnit,
que es extremadamente simple de usar,
y extremadamente eficiente para configurar desarrollos ágiles.
Les recomiendo encarecidamente que los usen, Definir pruebas es muy fácil.
La gran ventaja es que cuando has creado una prueba
Puedes ejecutarlo un millón de veces. y es muy útil para asegurarte
que su código sigue funcionando, incluso si has cambiado cosas,
y se han producido efectos de borde, puedes detectarlos
si has estado actualizado suficiente en las pruebas que has escrito.
Puedes ir más allá creando pruebas. mediante el uso de marcos de punto,
típicamente marcos falsos como BabyMock, etc ...
tener diferente estilos de prueba y prueba de escritura.
Lo invito a usar y crear muchas pruebas en tu programa