Haz cambios probados y listos para revisión en una base de código grande

## Compila y ejecuta las pruebas solo con el wrapper del proyecto Los proyectos grandes suelen envolver su compilador y su ejecutor de pruebas en un único comando del proyecto que recompila e inyecta tus cambios locales antes de ejecutar nada. Compila y ejecuta siempre a través de ese wrapper. Nunca invoques directamente el ejecutor de pruebas sin procesar ni un binario compilado previamente, porque eso ejecuta artefactos obsoletos que no incluyen tu cambio, así que un resultado exitoso no demuestra nada. Aprende qué ediciones pueden saltarse la recompilación nativa. Los cambios que solo afectan entradas no compiladas, como declaraciones de tipos o scripts empaquetados que se recargan por sí solos, no necesitan una compilación completa, y forzarla solo desperdicia tiempo; en esos casos, ejecuta directamente la verificación específica más ligera. No pongas un límite de tiempo a una compilación completa. Una compilación en frío legítima puede tardar bastante, y cancelarla produce fallos confusos y engañosos. Cuando el wrapper reenvía los argumentos finales al programa compilado, coloca las opciones de compilación antes de esos argumentos de ejecución para que el enrutamiento no sea ambiguo. ## Añade las pruebas al archivo de pruebas existente del código que cambias Por defecto, añade tu prueba al archivo de pruebas ya existente para el código que estás modificando. Un error en el comportamiento de un área pertenece al archivo de pruebas existente de esa área, no a uno nuevo. Mantener una prueba junto a la cobertura relacionada es lo que la hace fácil de encontrar y evita configuraciones duplicadas. Sigue la estructura de pruebas ya establecida en el repositorio: pruebas unitarias agrupadas por subsistema, pruebas de compatibilidad, pruebas de plataforma y de API web, pruebas de línea de comandos, y pruebas de integración de extremo a extremo, cada una en su propia área. Coloca tu prueba donde ya vive una cobertura equivalente. Reserva las carpetas de propósito especial exactamente para el caso al que están destinadas. Una carpeta de regresiones identificada por un número de incidencia es solo para una regresión real, es decir, un comportamiento que funcionaba en una versión anterior y luego se rompió, y ese identificador debe ser real, nunca un marcador de posición. Si el comportamiento nunca fue correcto, no es una regresión, y la prueba pertenece al archivo ordinario de ese módulo. ## Escribe pruebas que den el mismo resultado en cada ejecución Prefiere las aserciones por snapshot antes que comprobaciones de igualdad frágiles sobre salidas grandes, y normaliza el snapshot para que valores incidentales, como rutas temporales, no generen cambios innecesarios. Nunca escribas una prueba que solo verifique la ausencia de un cierre inesperado o de una cadena de excepción no controlada; ese tipo de prueba nunca puede fallar en el pipeline y da una falsa sensación de seguridad. Elimina cualquier fuente de no determinismo. No fijes un puerto de red de forma manual; enlaza a un puerto efímero y recupera el que se asignó. Nunca uses una pausa ni un temporizador para esperar algo, porque lo que pruebas es la condición, no el paso del tiempo; espera la condición real en su lugar. Usa el ayudante de directorios temporales del arnés de pruebas en vez de crear directorios temporales a mano, y evita utilidades de shell como la búsqueda de archivos o de texto dentro de una prueba, usando en su lugar las API de archivos propias del proyecto. Cuando una prueba lanza un proceso, verifica su salida antes de verificar su código de salida, para que un fallo dé un mensaje útil en lugar de un simple estado distinto de cero. ## Comprueba que las pruebas nuevas fallan sin el cambio e informa solo lo que ejecutaste Un cambio no está terminado hasta que se ha probado. Si no ejecutaste las pruebas, asume que el código no funciona; ejecutarlas forma parte de terminar el trabajo, no es un seguimiento opcional. Demuestra que cada prueba nueva realmente ejercita tu cambio. Debe fallar contra la base sin modificar y pasar contra tu compilación. Una prueba que ya pasa sin tu cambio no demuestra nada, así que confirma ambas direcciones antes de confiar en ella. Sé humilde y honesto en cada mensaje de commit, respuesta de revisión y actualización de estado. Nunca exageres lo que lograste ni lo que realmente funciona. Informa solo los resultados que has observado en tu propia ejecución, y expresa con claridad qué sigue sin verificar o sin terminar, en lugar de dar a entender que el trabajo está completo. ## Entiende cómo está organizada la base de código antes de editarla Antes de editar, aprende cómo está organizada la base de código: qué capa es responsable de qué, dónde viven las utilidades compartidas y qué archivos son generados frente a los escritos a mano. Los archivos generados se producen a partir de definiciones fuente, así que edita la fuente y deja que la compilación los regenere; nunca edites a mano una salida generada, porque la siguiente compilación la sobrescribirá. Identifica el subsistema responsable del comportamiento que estás tocando, ya sea el análisis sintáctico, la resolución de módulos, las API en tiempo de ejecución, las redes, el almacenamiento, el empaquetador o el gestor de paquetes, para que tanto tu cambio como su prueba terminen en el lugar correcto. Sigue el estilo de código existente. Revisa los archivos vecinos para identificar los patrones ya establecidos y ajústate a ellos en lugar de importar convenciones de otro proyecto. Prefiere el modismo propio del lenguaje para la gestión de recursos, como la limpieza automática basada en el alcance, antes que el desmontaje manual, y respeta los casos límite documentados, por ejemplo valores asignados en una región que omite sus destructores al reiniciar y que deben liberarse explícitamente primero. ## Lee las reglas de revisión y sigue las convenciones obligatorias del proyecto Un proyecto maduro condensa en un conjunto de reglas escritas aquello por lo que sus revisores bloquean las fusiones. Léelo antes de escribir código que tome una decisión no evidente, y lee cualquier guía específica del área que estés tocando, como capas de compatibilidad, diseño de API de cara al usuario, rutas críticas sensibles al rendimiento, código condicionado por plataforma, cambios de dependencias y de vendoring, o documentación y declaraciones de tipos, antes de realizar ese trabajo concreto. Cumple exactamente con las convenciones obligatorias del proyecto, porque el pipeline automatizado las hace cumplir. Usa el prefijo de nombre de rama exigido, mantén los comentarios de código breves, con las explicaciones más profundas trasladadas a la documentación y escritas solo cuando se solicitan explícitamente, y usa rutas absolutas en las operaciones de archivos. Cuando hagas un cambio específico de plataforma, compila para todos los objetivos compatibles, ya que el código compilado condicionalmente no se verifica de tipos a menos que su objetivo correspondiente se compile realmente. ## Usa las herramientas de diagnóstico del proyecto si falla la compilación, y corrígelas si muestran datos erróneos Cuando una compilación automatizada falla, usa los comandos de diagnóstico dedicados del proyecto, los que muestran las pruebas fallidas, resumen el estado de los trabajos y guardan los registros completos, en lugar de reconstruir ese panorama a mano. Estos ya separan los fallos nuevos de los que también fallan en otros lugares y filtran el ruido habitual. Cuando leas la retroalimentación sobre un cambio, usa el comando que devuelve el panorama completo. Un listado general suele omitir en silencio los resúmenes de revisión y los comentarios a nivel de línea, así que prefiere la herramienta que devuelve juntos los comentarios de nivel superior, las revisiones y los comentarios en línea, en una única vista cronológica y etiquetada. Si la salida de un ayudante parece incorrecta, como una anotación mal interpretada o un campo cuya forma de origen cambió, corrige el propio presentador en lugar de sortear el problema más adelante. El ayudante es una capa delgada sobre la herramienta subyacente, y repararlo mantiene correctas todas las ejecuciones posteriores.