Cuestionario Testing Flashcards
¿Cuál es la historia de vida de una persona que trabaja en software? (la famosa foto)
- Alguien tiene una necesidad o problema o una oportunidad de negocio
- Le damos forma, una visión del proyecto
- Generamos un backlog
- Empezamos a trabajar de forma iterativa (onda scrum)
- Al final de cada iteración tenemos un entregable al cual le corremos algún tipo de verificación para ver que el P.O o la gente de negocio este conforme
- Lo ponemos en producción y lo ven los usuarios finales
- Empezamos a ganar plata
- Le damos una vuelta para ganar más plata y volvemos a arrancar desde el 1.
¿Qué es QA y QC?
QA : Quality Assurance / Aseguramiento de Calidad.
Tiene que ver con procesos
QC : Quality Control / Control de Calidad.
Tiene que ver con testing
¿Mejoramos la calidad con el testing?
No
El testing es un feedback
Con el verificamos cual es la calidad que tenemos y en base a eso tomamos una decisión de si damos una vuelta de rosca o cambiamos algo
Pruebas unitarias
Cuando estoy testeando un componente chiquito de manera aislada
Son sencillas de hacer, corren rápido y muy puntuales
Pruebas de API o de Servicio
Cuando estoy testeando un conjunto de componentes que interactúan entre sí que ya no están aislados
Pruebas de punta a punta (end2end) o de UI
Cuando se testea la aplicación desde la perspectiva del usuario
Son dificiles de codear, es más compleja de ejecutar y el feedback es mucho menos específico
¿Qué es la arquitectura de prueba?
Es lo que le permite a un individuo (tester / user / developer) testear un componente (clase / componente / servicio / API / UI)
¿Qué componentes tiene la arquitectura de prueba?
- Lenguaje : permite especificar la prueba (varía según quién sea el individuo, no es lo mismo un usuario que un developer)
- Interprete : para que interprete el lenguaje
- Driver : dependiendo de que sea lo que quiero testear, necesito algún tipo de Driver para comunicarme con eso (ejemplo : cola MSQ necesito una librería específica).
- Librería de aserciones : cuando hacemos pruebas, ejecutamos una acción y después hacemos un assert
- Runtime : se encarga de articular la ejecución de todo
¿Cómo diseñamos nuestras APPs para asegurarnos de que sean testeables?
- Arquitectura hexagonal
Propone que aislemos la lógica central de nuestro dominio manteniendola separada del mundo exterior (operaciones de entrada / salida, de base de datos, etc). Resolverlas a partir de un patrón de ports y adapters
¿Qué es la inyección de dependencias?
En lugar de que un objeto cree sus propias dependencias, estas le son proporcionadas (inyectadas) desde el exterior.
¿Cuáles son los tipos de Test Doubles?
Son clases que se utilizan en los tests reemplazando componentes que quiero aislar.
- Dummies : cuando tenemos un objeto que necesitamos para relleno (ej : necesitas invocar un método que tiene un parámetro que no te importa lo que le pases básicamente para que el compilador no se queje)
- Fakes : objeto de mentira, se suele utilizar en las bases de datos para evitar testear con un postgress por ejemplo
Objetos con cierta inteligencia adicional :
- Stubs
- Mocks
¿Deberías mockear las cosas que no están bajo nuestro control?
No
Porque si ese sistema externo cambia su comportamiento, uno cree que funciona de una forma y en realidad está funcionando de otra y es un problema.
¿Qué pasa si decido mockear algo que no está bajo mi control?
Debo hacer pruebas de contrato contra esa entidad externa.
Si estas fallan tendré que ver que es lo que cambio y actualizar mi sistema.
Ej de herramientas : Wiremock y Pack
¿Qué son las Feature Flags?
Es que cuando construís tu aplicación, tengas la capacidad de apagar funcionalidades.
En caso de los tests, se utiliza para testear funcionalidades que hay que tener en producción para ser testeadas pero no estoy seguro de que no vayan a romper nada en el ambiente de producción. Se puede habilitar solo para un par de usuarios para testearla o a nadie.
