Evaluación integral del Módulo 6 cubriendo performance, seguridad, microservicios, colas de mensajes, bases de datos, webhooks, contract testing y documentación de API.
Lo Que Aprenderás
Demostrar comprensión integral del testing de API y backend cubierto en el Módulo 6
Aplicar conceptos de API testing a escenarios realistas combinando múltiples temas
Diseñar una estrategia completa de API testing integrando conocimiento de todo el módulo
Diseña una estrategia completa de API testing para una plataforma de citas médicas con cumplimiento HIPAA, SLA de 99.9%, y 10,000 usuarios concurrentes.
Cubre: niveles de tests, seguridad, rendimiento, integraciones y datos.
Prueba de Conocimiento
1. ¿Cuál es el propósito principal del performance testing de API?
El performance testing de API mide cómo se comporta la API bajo carga: throughput (RPS), percentiles de latencia (p95, p99) y tasas de error. Identifica puntos de quiebre y valida que los SLAs se cumplan.
2. ¿Qué vulnerabilidad OWASP API ocurre cuando un usuario puede acceder a datos de otro usuario cambiando un ID de objeto?
BOLA (API1:2023) es la vulnerabilidad de API más común. Ocurre cuando la API no verifica que el usuario autenticado tenga permiso para acceder al objeto específico identificado por el ID.
3. En una arquitectura de microservicios, ¿qué verifica un component test?
El component testing verifica un solo microservicio como un todo, con dependencias externas reemplazadas por test doubles. Prueba los endpoints, lógica de negocio y manejo de datos sin requerir otros servicios.
4. ¿Cuál es la diferencia fundamental entre Kafka y RabbitMQ?
RabbitMQ es un message broker que elimina mensajes una vez consumidos y confirmados. Kafka es una plataforma de event streaming que retiene mensajes en particiones de topics, permitiendo replay.
5. En arquitectura event-driven, ¿por qué los consumidores deben ser idempotentes?
Los sistemas distribuidos comúnmente usan entrega at-least-once. Un consumidor puede recibir el mismo evento dos veces por retries o problemas de red. El procesamiento idempotente previene efectos secundarios duplicados.
6. ¿Qué significa ACID en transacciones de base de datos?
ACID garantiza: Atomicidad (todas las operaciones tienen éxito o todas fallan), Consistencia (la BD pasa de un estado válido a otro), Aislamiento (transacciones concurrentes no interfieren), Durabilidad (datos committed sobreviven fallas).
7. ¿Cuál es la verificación más crítica en testing de migración de datos?
La completitud y precisión de datos son primordiales. Cada registro debe contabilizarse con transformaciones correctas. Datos faltantes o corruptos en producción son extremadamente costosos de corregir.
8. ¿Cómo difieren los webhooks del polling de API?
Los webhooks son push-based: el proveedor envía HTTP POST cuando ocurren eventos. El polling es pull-based: tu sistema pregunta repetidamente por actualizaciones. Los webhooks son más eficientes y de menor latencia.
9. En consumer-driven contract testing con Pact, ¿qué pasa cuando la verificación del proveedor falla?
Una verificación de proveedor fallida significa que el proveedor rompería a un consumidor si se despliega. Debe corregir el cambio o coordinar con el consumidor para actualizar el contrato.
10. ¿Qué es el drift de documentación en el contexto de API testing?
El drift ocurre cuando los desarrolladores cambian la API sin actualizar la documentación. Herramientas como Dredd y Schemathesis lo detectan comparando schemas documentados contra respuestas reales en pipelines CI/CD.