Revisión Humana
Para cada cambio, pregúntate: ¿qué requisito satisface, qué comportamiento altera y puede un mecanismo existente realizar el trabajo?
Las solicitudes de solo revisión no autorizan ediciones. Sigue las convenciones del proyecto y el alcance del usuario, incluidos los límites de pruebas y publicación.
Rastrear el comportamiento
Compara las rutas de ejecución antiguas y nuevas, incluyendo llamadores y ramas de omisión. Distingue entre pasar un objeto, pasar una fábrica e invocarlo. Determina quién posee el estado, cuándo se carga y qué operaciones ven un reemplazo.
Investiga la duplicación aparente antes de eliminarla. ¿Qué cambio anterior hizo necesaria esta operación? Una nueva implementación puede haber perdido una verificación implícita de inicio o una limpieza. Verifica las ramas antes de afirmar que el trabajo sucede dos veces.
Revisa el momento del fallo, los reintentos, la limpieza de recursos y si la causa original llega al usuario. Un error que se mueve del inicio a la configuración de la conexión puede cambiar el comportamiento incluso cuando ambas rutas fallan eventualmente. Revisa a los consumidores antes de tratar un tipo de excepción interna como un requisito de compatibilidad.
Simplificar la capa responsable
Primero inspecciona lo que el componente receptor ya admite. Si su contrato es suficiente, corrige lo que el llamador proporciona en lugar de agregar otra responsabilidad al receptor. No muevas trabajo a un constructor compartido solo para que los llamadores se vean iguales.
Justifica cada operación, campo, rama o abstracción añadida por la tarea actual. Para las eliminaciones, revisa los llamadores dependientes y las garantías. Prefiere un contrato compatible existente; conserva adaptadores que realicen una conversión significativa o impongan un contrato.
Sigue el estado y el trabajo a lo largo de toda la ruta afectada. Eliminar un caché no soluciona un estado obsoleto si un llamador captura el mismo valor en un cierre. Por el contrario, un proveedor dinámico y una alternativa basada en archivos pueden cargar intencionalmente en momentos diferentes. Unificarlos puede introducir una regresión.
Juzga la simplicidad por los conceptos, los propietarios del estado y la indirección que un lector debe rastrear. Un diff más pequeño no siempre es un diseño más claro. Evita el formato no relacionado y la preparación para tareas futuras.
Probar el requisito
Cada prueba debe contar un caso coherente a través de su nombre, entradas, acciones y resultado esperado. Conserva solo la configuración y las afirmaciones que establecen ese caso. Varias fases pertenecen juntas cuando la garantía las necesita, como la recuperación después de un fallo; los casos no relacionados no.
Mantén el conjunto más pequeño que distinga los comportamientos requeridos y las regresiones. Los recuentos internos de llamadas importan solo cuando expresan un requisito, como cargar una vez. Confirma que un fallo inyectado realmente ocurrió: un tiempo de espera o un socket cerrado por sí solos pueden pasar por la razón equivocada.
Ordena las pruebas por comportamiento relacionado para que el lector lleve contexto útil a la siguiente. Usa nombres concretos en lugar de comentarios explicativos. Trata un comentario como una señal para mejorar primero el código; conserva las razones que no se pueden expresar claramente en nombres o estructura.
Antes de agregar un fixture personalizado, espera, aserción o ayudante de recurso, busca un marco existente o una facilidad de clase base. Prefiere código directo. Comparte la configuración repetitiva cuando siga siendo comprensible, pero mantén visibles las entradas y acciones específicas del escenario. Evita callbacks, banderas o ayudantes de propósito general que ahorren líneas ocultando el caso.
Sincroniza con el evento que necesita la aserción, no con un retraso o un evento anterior en otro hilo. Preserva la limpieza en caso de fallo. Lee las pruebas finales en secuencia sin el diff y verifica que su propósito sea claro sin la conversación.
Explicar y entregar
Conserva los comentarios que explican una razón no obvia y evitan una simplificación incorrecta plausible. Elimina la narración de operaciones obvias. Mantén los contratos de la API precisos y las instrucciones al usuario accionables; lee las secciones editadas sin el diff para verificar que se sostengan por sí mismas.
Trata tanto el diagnóstico del usuario como tu primera impresión como hipótesis. Reporta hallazgos respaldados con un escenario desencadenante, consecuencia, evidencia y la corrección útil más pequeña. Separa los defectos de las preguntas abiertas y las mejoras opcionales. Ningún hallazgo es un resultado válido.
Para un rediseño sustancial, explica una ejecución concreta, qué se vuelve más simple y el costo de comportamiento o compatibilidad. Resuelve las opciones fuera del alcance acordado con el usuario; continúa con las correcciones autorizadas de rutina sin otra aprobación.
Después de las correcciones, lee el flujo completo afectado y el diff final. Reporta conclusiones, verificaciones realizadas y brechas restantes, en lugar de narrar una pregunta por cada línea.