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
- Lógica
una función, datos de entrada y salida. Rápida, sin servidor ni navegador.
- API
la petición completa y la respuesta esperada: código, cuerpo, base de datos.
- Interfaz
la acción humana simulada: escribir, clic, ver. Atrapa lo que las otras no ven.
El pedido de suite de API
El contrato probado, extremo a extremo
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.
La misma prueba manual que ya hacías, pero repetible
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
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:
Marca la línea o las líneas con error y pulsa Comprobar.
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.
Cuando tus pruebas corren solas cada día, dejaste de confiar en la memoria y empezaste a confiar en la evidencia.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.