Back to SDET

Conceptos y Ejercicios de Testing

Looking for JavaScript fundamentals (variables, promises, classes…)? They live in the JavaScript path.Go to JavaScript →
¿Cuáles son los tipos de test doubles?
Un test double es cualquier sustituto de un componente real. Dummy: se pasa pero nunca se usa. Stub: devuelve valores fijos predefinidos. Fake: una implementación funcional pero simplificada (p. ej. una BD en memoria). Spy: registra cómo se le llamó sin cambiar el comportamiento. Mock: un stub más aserciones sobre cómo se le llamó (p. ej. que sendEmail se llamó una vez).
¿Por qué y cuándo se mockea, y cuándo no?
Mockea para aislar la unidad bajo test de dependencias externas lentas o inestables (BD, APIs de terceros, email), para simular errores difíciles de reproducir como un 500, y para mantener los tests rápidos y deterministas. No mockees cuando quieres verificar específicamente la integración real, cuando un mock se alejaría tanto de la realidad que pierde valor, o cuando la dependencia real ya es local y rápida.
¿Cómo se mockean peticiones de red en Playwright?
Usa page.route para interceptar un patrón de URL y resolverlo con una respuesta predefinida: page.route('**/api/products', r => r.fulfill({ status: 200, body: JSON.stringify(data) })). Puedes devolver un 500 para probar la UI de error, o añadir un retardo antes de route.continue() para probar estados de carga — todo sin tocar el backend real.
¿Cómo se estructura un test de integración CRUD para una API REST?
Cubre el ciclo de vida completo y los límites de auth/validación: crear (POST -> 201), leerlo (GET -> 200), actualizar parcialmente (PATCH -> 200, los campos no enviados se mantienen), eliminar (DELETE -> 204) y confirmar que ya no existe (GET -> 404). Añade casos negativos: sin token -> 401, rol incorrecto -> 403, falta un campo obligatorio -> 422, duplicado -> 409. Cada test debe preparar sus propios datos para ser independiente.
¿Qué es el TTL y dónde importa en testing?
El TTL (time to live) es cuánto tiempo algo sigue siendo válido: tokens/sesiones de auth (caducidad del JWT), entradas de cache (Redis, CDN, Cache-Control de HTTP) y ventanas de rate-limit (X-RateLimit-Reset). Como SDET pruebas que un token caducado se rechaza, que una entrada de cache es un miss tras su TTL, y que las peticiones que superan el límite se limitan y se reinician correctamente.
¿Por qué evitar los sleeps fijos y qué se usa en su lugar?
Un sleep fijo (waitForTimeout(3000)) es demasiado corto (flaky) o demasiado largo (lento), porque el timing real varía. Usa esperas basadas en condiciones: waitForSelector para un elemento, expect(...).toBeVisible(), waitForResponse para una llamada de API, o un helper de polling genérico que reverifica una condición hasta un timeout. Esto hace los tests más rápidos y más fiables.
¿Cómo funcionan los reintentos con backoff exponencial y cuándo no reintentar?
El retry reejecuta una operación fallida hasta N intentos, esperando más entre cada intento (delay * 2^intento) para que un servicio en apuros se recupere sin saturarlo. Reintenta solo fallos transitorios (cortes de red, 5xx, timeouts). No reintentes errores de cliente deterministas como un 404 o 422 — un predicado shouldRetry te permite saltarlos, ya que reintentar nunca tendrá éxito.