115 lines
4.1 KiB
Markdown
115 lines
4.1 KiB
Markdown
### Testing
|
|
***Solo se detalla:***
|
|
Test Unitario Automático
|
|
|
|
Los test poseen una estructura interna común:
|
|
- **Anatomía de los Tests**
|
|
- ***Setup***:
|
|
Es donde se crean los objetos necesarios (el contexto) para el test.
|
|
|
|
- ***Act***:
|
|
Acción a realizar o probar.
|
|
|
|
- ***Assertions***:
|
|
Verificaciones sobre resultados obetnidos.
|
|
```
|
|
Los assertions son afirmaciones que gerealmente
|
|
chequean el estado del sistema, comparando los resultados
|
|
obtenidos con los esperados.
|
|
|
|
Algunos métodos de la clase TestCase:
|
|
- assertEqual - assertNotEqual - assertTrue - assertFalse - assertRises
|
|
```
|
|
|
|
|
|
- **Caracteristicas deseables de los test**
|
|
- Ser de rápida ejecución.
|
|
- Ser reducidos en tamaño.
|
|
- Ser entendibles.
|
|
- Debe tener 1 test por caso.
|
|
- Debe tener control de todo.
|
|
- "misma cantidad de lineas de código q las del sistema".
|
|
- Nombres declarativos y resumir el:
|
|
***GIVEN*** / ***WHEN*** / ***THEN***
|
|
|
|
- **Buenas practicas**
|
|
```
|
|
- Testear un caso por test (no implica tener solo un assert)
|
|
|
|
- Empezar siempre por el test mas sencillo.
|
|
|
|
- Comenzar por la aserción, ayuda a entender qué se quiere hacer.
|
|
|
|
- Siempre debe haber un assert en el test (o fail, etc).
|
|
|
|
- Recordar testear casos "negativos" (posibles fallas), no solo "positivos".
|
|
|
|
- Recordar que el test debe estar en cotrol de todo:
|
|
*En el caso de testeo sobre secuencias:
|
|
Verificar la longitud que debe tener y que estén unicamente los objs. que
|
|
deben estar.
|
|
```
|
|
|
|
- **Clasificación de Test según funcionamiento**
|
|
- Test Insoportables: Tardan mucho, posible uso de algún recurso lento (bd, conex, etc).
|
|
- Test Fragiles: Se "rompen" cuando se modifica la implementación interna de un objeto. Son test de "caja blanca".
|
|
- Test Erraticos: Aveces funcionan, otras no. Hay dependencias de "pictures" entre test o usan recursos externos.
|
|
|
|
#### Framework Xunit
|
|
Frameworks de desarrollo guiado por por pruebas
|
|
conocidos colectivamente como xUnit.
|
|
Disponibles para otros lenguajes y plataformas.
|
|
|
|
#### Librería Unittest
|
|
|
|
Framework de test unitarios **unittest** de la libreria estándar.
|
|
Inspirado en *JUnit*.
|
|
|
|
Similar a la mayoria de los frameworks de otros lengajes.
|
|
Soporta automatización de test, código compartido para setup y shutdown de test,
|
|
agregar test en colecciones e independencia de tests respecto del framework de reporte.
|
|
|
|
##### Componentes Xunit
|
|
|
|
* **Test Fixture :** Representa la preparación necesaria para correr uno o más test,
|
|
y cualquier acción de limpieza asociada.
|
|
|
|
* **Test Case :** Unidad de prueba individial.
|
|
|
|
Ademas de definir los metodos de Assertions, define también:
|
|
|
|
- setUp:
|
|
Llamado antes de ejecutar cada test del TestCase.
|
|
Aqui va el código para preparar el contexto del test
|
|
|
|
- tearDown:
|
|
LLamado al finalizar cada ejecución de test del TestCase.
|
|
Aquí va el código para limpiar el contexto que pudo haber modificado el test.
|
|
|
|
- setUpClass:
|
|
Ejecutado cuando se crea una instancia del TestCase.
|
|
Utilizado para hacer un setup del contexto común entre todos los test del TestCase.
|
|
|
|
- tearDownClass:
|
|
Ejecutado cuando se destruye una instancia del TestCase.
|
|
Utilizado para hacer limpieza del contexto. Evitando que afecte otros TestCase.
|
|
|
|
- addCleanup:
|
|
Agrega una función de limpieza que se ejecutará en el teardown del test.
|
|
Al agregar "muchas" opciones, estas se ejecutarán en orden LIFO.
|
|
|
|
|
|
|
|
* **Test Suite :** Colección de test cases, test suites o ambos.
|
|
|
|
* **Test Runner:** Coordina la ejecución de test y provee el Output al usuario.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|