Buscar/Corregir un defecto reproduciéndolo primero con una prueba que falle

Corregir un defecto reproduciéndolo primero con una prueba que falle

Úsalo cuando se reporta un defecto. La IA decide a qué parte pertenece, reproduce lo que ve el usuario en una prueba que falla, encuentra la causa real, aplica la corrección mínima, conserva la prueba para que no vuelva y repite los pasos del usuario para confirmarlo.

Para usar estas reglas de IA
## Decidir a qué parte del sistema pertenece el defecto antes de tocar el código Comienza por el impacto observable, no por el archivo donde apareció el síntoma. Un resultado útil de la evaluación inicial indica al siguiente investigador qué falló, quién o qué está afectado y qué componente es responsable del comportamiento. ### Clasifica antes de actuar - Clasifica el defecto como un problema del comportamiento central, del comportamiento del sistema o de la integración, o del entorno anfitrión. - Distingue el componente que muestra el síntoma del componente que controla el comportamiento defectuoso. - Dirige el trabajo al ámbito responsable cuando las evidencias apunten fuera del componente actual. ### Define el límite de las evidencias Registra la entrada desencadenante, el estado inicial, las acciones exactas del usuario, el resultado esperado, el resultado real y el entorno pertinente. Separa los hechos de las hipótesis. No edites el código de implementación durante la evaluación inicial; la etapa siguiente debe establecer primero un fallo reproducible. La clasificación es provisional. Si las evidencias posteriores la contradicen, vuelve aquí, revisa el límite y traslada la prueba a la capa que realmente controla el comportamiento. ## Reproducir lo que ve el usuario con una prueba que falle Convierte el informe en el escenario repetible más corto que siga coincidiendo con lo que experimenta el usuario. Conserva la entrada, el estado, la secuencia y el resultado visible que sean relevantes; elimina la preparación incidental que no influya en el fallo. ### Elige la capa de prueba fiable más cercana - Usa una prueba unitaria o de componente específica para la lógica aislada. - Usa una prueba de integración o del sistema cuando intervengan la persistencia, la representación visual, el transporte o varios componentes. - Usa una prueba en navegador o de extremo a extremo cuando el fallo dependa de la interacción real, el foco, los tiempos, la navegación o el estado visual. Escribe la prueba de regresión antes de cambiar el código fuente. Ejecútala y confirma que falla por el motivo informado, no por una preparación defectuosa, recursos obsoletos, datos ausentes o una aserción no relacionada. Una prueba que nunca se haya observado fallar no demuestra la existencia del defecto. Si el comportamiento no puede automatizarse, documenta el motivo y captura la alternativa repetible más sólida, como un procedimiento manual determinista, una secuencia de capturas de pantalla, un rastro o un resultado medido. Mantén sin cambios el código de implementación hasta que las evidencias del fallo sean fiables. ## Encontrar el primer punto donde el comportamiento se desvía y aislar la causa raíz Investiga solo después de que la reproducción del fallo sea estable. Formula varias hipótesis plausibles y compruébalas mediante observaciones específicas, en lugar de cambiar varias cosas a la vez. ### Rastrea la primera divergencia Sigue la entrada defectuosa a través de los cambios de estado, los límites y el flujo de control. Compara un caso correcto con el caso defectuoso y encuentra el primer punto donde el comportamiento real se desvía del esperado. Inspecciona los artefactos generados, los valores persistidos, las respuestas de integración o los tiempos solo cuando la reproducción indique que son relevantes. Para cada hipótesis, predice qué evidencia la confirmaría o la descartaría, ejecuta la comprobación discriminante más pequeña y registra el resultado. Distingue la causa raíz de los daños posteriores y de las condiciones que solo facilitan la observación del error. No modifiques la lógica de producción mientras aíslas la causa. Si todas las hipótesis fallan, vuelve a la reproducción, verifica sus supuestos, perfecciona la clasificación y formula una nueva hipótesis respaldada por evidencias. ## Aplicar la corrección mínima y conservar la prueba para evitar regresiones Una vez aislada la causa raíz, modifica la superficie más pequeña que restablezca el comportamiento previsto. Conserva los contratos públicos y el comportamiento no relacionado, y evita cualquier limpieza, rediseño o refactorización que no sea necesaria para el caso defectuoso. Ejecuta primero la prueba que fallaba originalmente. Ahora debe superarse porque se eliminó la causa, no porque se debilitó la aserción, se omitió el escenario o el entorno de prueba dejó de ejercitar el error. Conserva la prueba como protección permanente contra regresiones. Después, ejecuta el grupo de pruebas directamente afectado y las comprobaciones estáticas, de estilo o de tipos pertinentes. Amplía la ejecución a un conjunto mayor solo cuando el cambio atraviese límites compartidos o las evidencias más acotadas revelen un riesgo más amplio. Trata cada nuevo fallo como evidencia: corrige una regresión real o vuelve al aislamiento de la causa raíz si la corrección propuesta estaba incompleta. Revisa la diferencia final para detectar ediciones accidentales, lógica duplicada, validación debilitada y casos límite ausentes. En esta etapa, la corrección solo está completa cuando el comportamiento específico y los elementos directamente relacionados superan todas las comprobaciones. ## Repetir los pasos del usuario en un entorno real antes de darlo por corregido Las pruebas automatizadas son necesarias, pero no sustituyen la confirmación de la ruta real del usuario. Repite el procedimiento original orientado al usuario en un entorno de ejecución representativo, usando la misma entrada y el mismo estado relevantes que expusieron el defecto. Compara el resultado anterior y el posterior en el límite visible. Cuando corresponda, confirma también el resultado persistido, la salida representada, el evento emitido, la transferencia de la integración o el artefacto reconstruido del que depende finalmente el usuario. Registra el entorno, los pasos y el resultado observado para que otra persona pueda verificar la conclusión. Si el comportamiento manual sigue fallando, difiere del resultado automatizado o requiere una solución provisional no documentada, no declares resuelto el defecto. Vuelve a la clasificación o a la reproducción, actualiza la prueba para cubrir la condición omitida y repite el ciclo de causa, corrección, regresión y validación. Finaliza con un informe conciso de evidencias: clase de defecto, reproducción confirmada, causa raíz, cambio mínimo, cobertura de regresión, comprobaciones directamente afectadas y resultado del flujo real. Añade una regla de prevención reutilizable solo cuando el defecto revele una familia arquitectónica recurrente; conserva los detalles puntuales en la prueba y en el historial de cambios.