| Temas |
|---|
| Que es el testing? |
| Que es un Test Limpio? |
| Cuando empezar a testear? |
| Cuando terminar de testear? |
| Diferencia entre coverage y confianza |
| Diferencia entre unit test e Integration Test |
| Que test de performance existen? |
| Que tipos de testing hay? |
| Que verifica el Unit Test? |
| Principios FIRST de los Unit test |
| ¿Qué código debería estar cubierto con pruebas unitarias? Imagina que quieres refactorizar la aplicación y moverla de Angular a React, por ejemplo. La UX y la lógica se mantienen igual. ¿Qué tipo de pruebas serían útiles en este caso? |
| ¿Qué tipo de pruebas utilizas en el proyecto? Imagina que estás comenzando una refactorización completa de la aplicación. ¿Qué tipo de pruebas podrían ayudarte a tener más confianza durante el proceso de refactorización? |
Mide la calidad del producto, el producto debe cumplir con lo que debería. El testing es para hacer visible la calidad
- Camino feliz, caso positivo
- Flujo normal de un caso de uso sin errores, por ejemplo un Login con datos válidos
- Por cada caso limpio “debería” tener 5 sucios
- Es el test más importante, el sistema debería hacer lo que debe hacer en principio.
Cuando hay una primera versión estable de los requerimientos, se debe ver si estos tienen sentido, etc.. Se deben encontrar errores en la etapa de definición para ahorrar tiempo y dinero en un futuro.
- Depende de diversos criterios que el tester y el desarrollador acordaron con anterioridad.
- Cuando se testeo y no se encontró ningún error
- Cuando hay un Fault-rate bajo (se debe cumplir con un estándar predeterminado)
- Ya se encontraron ciertos números de errores en total
- La confianza es que tan parecido son los test a un comportamiento que puede tener el usuario con nuestro sistema. Generalmente se refleja en el e2e.
- Coverage son la cantidad de lineas de codigo cubiertas por tests
Las pruebas unitarias (Unit testing) prueban los componentes individuales del software de forma aislada; son pruebas que generalmente realiza el mismo desarrollador. Es una prueba de caja blanca.
El test de integración (Integration Test) prueba la interfaz entre dos unidades o módulos del software, verificando cómo se comportan los módulos combinados entre sí. Se ejecuta después de las pruebas unitarias. Es una prueba de caja negra que generalmente realiza un tester.
| Unit Test | Integration Test |
|---|---|
| Se enfoca en una pieza específica del sistema de manera aislada | Se enfoca en la interacción entre unidades, módulos o componentes |
| Son más fáciles de escribir, más rápidas de ejecutar y más económicas de mantener | Son más complejas, más lentas de ejecutar y más costosas de mantener |
| Verifican la consistencia interna del código sobre el cual se tiene control total | Verifican cómo se integra tu código con otro código |
| No tienen dependencias externas; cualquier dependencia externa es simulada o eliminada | A menudo requieren interacción con dependencias externas, como bases de datos, servicios de red, hardware, etc. |
| Te indican la pieza exacta del código donde se encuentra el error | Indican qué módulos o componentes contienen el error |
| Son comparables a comprobar si una batería de un teléfono móvil está cargada o si la tarjeta SIM está activada | Son comparables a comprobar si la batería y la tarjeta SIM de un teléfono móvil están ensambladas para encender el teléfono |
- Load Test: Se simula el maximo uso del sistema, con maxima cantidad de usuarios.
- Stess Test: Se incrementara la cantidad de llamados a los servicios del sistema hasta que rompa, indicara la mayor cantidad de usuarios que el sistema podra soportar y cuanto tiempo tarda en recuperarse
- Resistance Test: Es test testear el sistema durante periodos de tiempo mas largos para revelar otros tipos de problemas.
- Test de aceleracion: Se testea como carga el contenido para usuarios con conexiones mas lentas.
- Peak Testing: Se simula que sucede con el sistema cuando llega a un pico de trafico
- Escalability Test: Testeamos, por ejemplo, cuanto podra el sistema escalar si agregamos otro servidor, o escalamos la instancia ya existente.
- Prueba de volumen:
- Que el software soporte muchos datos
- Enfocado en base de datos y transacciones
- Integracion - Integration: Que un código con otro se integre bien, a veces lo hace el tester o el dev, Ejecutada por el integrador
- Unit:
- Código que prueba una unidad de código, envió valores y veo lo que resuelve, por desarrolladores
- No es TDD (Desarrollo definido por pruebas).
- Es la primera etapa de prueba
- Static: Se identifican errores mientras se van escribiendo
- Test de Regresión:
- Es el test de todo, que una implementación no rompa algo ya hecho.
- Se hace en primera sobre casos positivos
- Test de Humo: Test rápido que verifica que la versión está estable (pocos test básicos, todos positivos por lo general)
- Prueba aceptación usuario: El usuario interactúa con el sistema, es casi siempre positivo, que lo que necesite funcione bien, esto en un entorno de testing en alpha
- Pruebas beta: Lo mismo que el anterior pero en un entorno productivo en prueba, el desarrollador no está presente. El mismo vuelve para recibir un feedback del usuario
Una prueba unitaria verifica la funcionalidad de los elementos más pequeños testables de una aplicación―clases y funciones―lo que permite a los desarrolladores detectar fallos y aislarlos. Las pruebas unitarias demuestran que, dado un determinado input, la función devuelve el resultado esperado. Una colección de pruebas unitarias conforma un conjunto de pruebas (test suite).
Rápido
Las pruebas deben ejecutarse rápidamente. Todo un conjunto de pruebas unitarias debería tomar segundos en ejecutarse. Cuanto más rápidas sean las pruebas, más de ellas podrás incluir en el conjunto y con mayor frecuencia podrás ejecutarlas. Cuando las pruebas se ejecutan lentamente, tu equipo no las ejecutará con frecuencia. Como resultado, es posible que no encuentres problemas lo suficientemente pronto como para corregirlos fácilmente, lo que limita tu capacidad para limpiar el código y resulta en un deterioro gradual de la calidad del mismo.
Independiente
Las pruebas no deben depender unas de otras. Una prueba no debe establecer las condiciones para la siguiente. Los miembros de tu equipo deberían poder ejecutar cada prueba de forma independiente y en cualquier orden. Cuando las pruebas dependen entre sí, la primera que falla provoca una cascada de fallos posteriores, dificultando el diagnóstico y ocultando defectos posteriores.
Repetible
Las pruebas deben ser repetibles en cualquier entorno. Si las pruebas unitarias pasan cuando se ejecutan una por una pero fallan al ejecutar todo el conjunto de pruebas, o si pasan en tu máquina de desarrollo pero fallan en el servidor de integración continua, hay un defecto de diseño. Tu equipo debería poder ejecutar las pruebas con éxito en el entorno de producción, en el entorno de QA y en las laptops, para que nunca haya una excusa para no hacerlo.
Autovalidación
Las pruebas deben tener una salida booleana y pasar o fallar. La misma prueba que falla ahora y pasa después es inestable y compromete todo el conjunto de pruebas. Las pruebas inestables llevan a consecuencias negativas. Los desarrolladores dejan de confiar en las pruebas y empiezan a ignorarlas, lo que dificulta identificar las pruebas no inestables que fallan en un mar de pruebas inestables. No deberías tener que leer un archivo de registro o comparar manualmente dos archivos de texto para determinar si una prueba pasa. Si no son autovalidantes, entonces el fallo se vuelve subjetivo y ejecutar las pruebas requiere una evaluación manual prolongada