Tres capas, tres tipos de prueba
No todo se prueba igual. La lógica (¿esta función con este dato devuelve esto?) se prueba instantáneamente y es barata. La API (¿este endpoint con esta petición responde este código y este cuerpo?) valida el contrato que tu frontend necesita. La interfaz (¿al hacer esta secuencia de clics aparece esta pantalla?) es la más parecida a tu prueba manual… pero automatizada y repetible. Cada capa dice cosas distintas que están rotas.
[Qué prueba cada capa]
Esta actividad interactiva ('Explicacion visual') requiere el motor completo de Lumbre. El contenido estatico se muestra arriba; para la experiencia interactiva, visita la version online de este objeto.
El pedido de suite de API
Crea una suite de pruebas de API para mis endpoints de contactos. Por cada endpoint quiero:\n- caso feliz: peticion valida -> codigo y forma de respuesta esperados\n- autenticacion: sin token -> 401\n- validacion: cuerpo vacio, email duplicado, nombre de 3000 chars -> 400 con mensaje\n- inexistente: GET y DELETE sobre id que no existe -> 404\n- estado: tras POST, GET lista el nuevo registro; tras DELETE, ya no esta\n\nUsa datos de prueba en una base separada, nunca mi base real.\nTermina con un reporte: total, pasadas, falladas y que significa cada falla en negocio.El pedido de suite de interfaz
Para la interfaz, piensa como usuario, no como sistema. Escribes la rutina (fluir de pantalla en pantalla) y la IA la traduce a un robot que la repite: abre el navegador real, hace clic, escribe y verifica lo visible. Un par de rutinas valientes (registro completo, crear-buscar-borrar un contacto) te avisan en segundos si algún cambio de la IA rompió el camino que tus usuarios recorren a diario.
Automatiza esta rutina de interfaz con un navegador real:\n1. abro la app -> veo el boton Nuevo contacto\n2. escribo nombre Ana, email ana@mail.com, pulsar Guardar\n3. veo "Guardado" Y Ana aparece en la lista\n4. recargo la pagina -> Ana sigue ahi\n5. busco "Ana" -> la lista muestra solo Ana\n6. pulso eliminar y confirmo -> lista vacia\n\nSi algo falla, el reporte debe decir en que paso fallo y capturar pantalla de ese momento.\nNo cambies nada de la app: solo observa y reporta.Leer el reporte como director
| Lo que dice el reporte | Qué significa | Tu siguiente orden |
|---|---|---|
| 28/30 pasadas, fallan «duplicado» y «sesión expirada» | dos contratos incumplidos, acotados | reporte de bug (M12) para cada rojo |
| Falla en el paso 3 de la rutina | el camino de uso se rompió ahí | pedir solo diagnóstico de ese paso |
| Todo verde tras un cambio grande | sospecha sana: ¿las pruebas comprueban algo? | pedir que rompan una prueba a propósito |
| La prueba de API tarda 10 minutos | probablemente toca red o datos enormes | pedir aislar: lógica rápida fuera de API |
Para reforzar
Criterios de aceptación y tareas pequeñas
OA publicado sobre criterios de aceptación: cada criterio que escribas se convierte directo en una prueba automatizable.
Prueba
La suite de API da todo verde, pero la rutina de interfaz falla en «tras recargar, Ana sigue ahí». ¿Qué capa tiene el problema más probable?
Las pruebas de API deben correr contra mi base de datos real para detectar bien los problemas.
Detecta la suite de riesgo
La IA propuso así el plan de pruebas. Señala la línea peligrosa:
- Suite de lógica: 12 casos, sin servidor, corre en segundos.
- Suite de API: base de datos de prueba separada, recreada en cada corrida.
- Suite de interfaz: corre contra la base de datos real para ser fiel al escenario.
- Reporte final: pasadas, falladas y pantalla capturada de cada falla.
Identifica la linea con error.
Pide a la IA una suite de API para TU proyecto con el prompt de este OA. Ejecútala, copia el reporte y convierte cada rojo en un reporte de bug con los 7 pasos de M12.