AnalyseDeCircuit/oxideterm

Auditoría de Pruebas de OxideTerm

Mantenga una protección de regresión útil en la capa que posee el comportamiento. Use la revisión más pequeña que resuelva el cambio solicitado; juzgue los resultados por los contratos preservados y los errores detectados, no por el número de pruebas o líneas eliminadas.

Lea el AGENTS.md aplicable. Ejecute los comandos desde la raíz del repositorio. La matriz de verificación y la guía de pruebas definen comprobaciones específicas del proyecto; esta habilidad proporciona las decisiones de calidad de las pruebas.

Elija el Alcance

• Escribir o cambiar una prueba: aplique las preguntas de autoría a ese comportamiento e inspeccione su cobertura existente más cercana.
• Diagnosticar una falla: establezca por qué falló la prueba y si la implementación, expectativa, fixture o entorno es incorrecto antes de editar.
• Auditar pruebas existentes: revise el módulo o comportamiento solicitado y registre evidencia para cada cambio propuesto. Amplíe a un subsistema completo solo cuando se haya solicitado ese alcance. Use el mismo estándar de evidencia para cada lote.

Crear o invocar esta habilidad no autoriza una limpieza amplia, subagentes, confirmaciones, envíos o PRs. Respete la autorización existente del usuario y cualquier límite de solo revisión. Cuando las ediciones ya estén autorizadas y la evidencia sea suficiente, proceda sin otra ronda de aprobación.

Preguntas de Autoría

Antes de agregar o cambiar una prueba, identifique:

1. El comportamiento observable o el contrato independiente que se está protegiendo.
2. Una regresión plausible y la aserción particular que fallaría.
3. Lo que la cobertura existente más cercana pasa por alto. Extienda esa cobertura cuando sea apropiado; otra capa necesita un riesgo de integración, protocolo o ciclo de vida distinto.
4. Si la prueba requeriría una exportación de producción, un switch, un wrapper o un gancho de inyección que no tenga un llamante de negocio. Prefiera probar en el límite de propiedad existente.

Use valores esperados independientes de la implementación. Los fixtures deben distinguir el comportamiento correcto del error probable: incluya candidatos excluidos al probar filtros, claves de ordenación diferentes al probar ordenamiento y entrada sensible real al verificar redacción. Un viaje de ida y vuelta de un campo de constructor, un resultado no vacío o un mock que realiza el comportamiento que se afirma es evidencia insuficiente del flujo de trabajo previsto.

Los ayudantes de prueba y los fixtures pueden ser legítimamente solo de prueba. La preocupación es distorsionar las API de producción o mantener vivo el comportamiento de producción obsoleto únicamente para las pruebas.

Diagnosticar una Prueba Fallida

Lea la prueba completa, sus entradas, la ruta de producción, la cobertura cercana y el historial de cambios relevante. Para CI, identifique la confirmación fallida, el trabajo, el nombre de la prueba y la aserción; una salida genérica distinta de cero no es una causa raíz. Inspeccione la fuente o los tipos de dependencia cuando la afirmación dependa de su comportamiento.

Clasifique la falla a partir de la evidencia:

• Regresión de producto: el contrato previsto aún se mantiene. Reproduzca la falla y repare la implementación propietaria dentro del alcance autorizado.
• Expectativa obsoleta: el historial y el contrato actual muestran un cambio de comportamiento intencional. Actualice el comportamiento esperado manteniendo la protección para los formatos y API lanzados compatibles.
• Prueba o fixture defectuoso: el caso no ejerce su condición declarada, depende de un estado accidental o falla por una razón no relacionada. Repare la configuración y las aserciones en el límite real.
• Fallo de entorno: la compilación, las dependencias, los recursos, la plataforma o los fixtures externos impiden que se pruebe el comportamiento. Reporte esa limitación; no lo reinterprete como una prueba que pasa u obsoleta.

Una falla de línea base no es una razón para eliminar una prueba. Para una corrección de errores, demuestre la falla prevista antes de la reparación y el éxito después. Reutilice la evidencia de CI válida o una línea base local capturada cuando demuestre la misma falla; no repita comprobaciones costosas únicamente para el ceremonial.

Por ejemplo, la prueba del plugin .oxide necesita distinguir la validación sin contraseña de la vista previa de importación descifrada. La respuesta de validación del formato cifrado no debe revelar metadatos; la vista previa con contraseña aún debe contener los nombres de descripción y conexión explícitamente esperados. Actualizar esas aserciones preserva el contrato sin otra prueba de descifrado de bajo nivel en la capa del plugin.

Auditar Antes de Editar

Lea cada candidato completamente, incluidas las filas de parámetros. Trace su punto de entrada de producción, llamantes, dependencias relevantes, implementaciones hermanas y pruebas superpuestas. Verifique el historial para conocer la razón por la que existe y el enrutamiento de CI para saber qué comprobaciones se ejecutan realmente.

Use un registro de evidencia compacto para los cambios propuestos, en la respuesta de trabajo a menos que se haya solicitado un informe guardado:

Prueba y ubicación	Comportamiento y falla creíble	Decisión	Prueba restante o reparada	Validación
Nombre y ruta exactos de la prueba	Lo que las aserciones pueden detectar	Retener / Reparar / Consolidar / Eliminar	Prueba o límite nombrado, con historial relevante	Comando enfocado o escenario manual

• Retener: protege de forma independiente un contrato significativo.
• Reparar: el comportamiento importa, pero la entrada, aserción, nombre o resultado esperado es incorrecto o demasiado débil.
• Consolidar: mueva aserciones distintas a la prueba principal nombrada antes de eliminar la configuración o el caso duplicado.
• Eliminar: nombre la prueba restante más sólida, o demuestre que el comportamiento ya no tiene un contrato compatible. La incertidumbre significa investigar o retener.

Para el código de producción eliminado con una prueba, también identifique sus llamantes que no son de prueba y por qué el código está obsoleto. Busque referencias antes de eliminar un ayudante, exportación, característica o fixture. No haga simplificaciones no relacionadas parte de la auditoría.

Patrones que Vale la Pena Investigar

• La prueba repite el texto fuente de la implementación, la forma de llamada privada o la representación interna exacta, y falla después de una refactorización que preserva el comportamiento.
• Varias capas llaman al mismo ayudante con entradas equivalentes y repiten sus aserciones sin ejercer su propia integración.
• Un fixture preordena el orden de devolución de llamada, la notificación de finalización o el resultado persistido que el propietario real debería producir.
• Una prueba de denegación es rechazada por la validación de parámetros antes de llegar a la verificación de permisos que afirma probar.
• Una prueba de concurrencia, cancelación o reactivación verifica solo una bandera final sin crear el trabajo competidor o el que espera.
• Una aserción de éxito verifica solo Ok, Some, longitud o no vacío cuando el contenido, la identidad, el orden o un efecto secundario duradero es el contrato.

Estas son señales de investigación, no reglas de eliminación automática. Preserve los valores predeterminados de seguridad independientes, los bytes del protocolo, los formatos de persistencia y migración, las API de plugins, el comportamiento de la plataforma, el empaquetado, la internacionalización y las restricciones de arquitectura. La inspección estática puede ser útil cuando protege un contrato real y sobrevive a un cambio de nombre irrelevante. La ejecución lenta por sí sola no hace que una prueba sea redundante.

Límites de OxideTerm

Comportamiento	Límite de verificación preferido
Análisis, normalización de configuración, serialización o fusión de datos	Crate de dominio propietario con valores esperados explícitos y muestras de formato compatibles
Compartición de nodos SSH, SFTP, reenvío, reconexión o hosts de salto	Propietario de tiempo de ejecución con registro de consumidores real, cancelación y limpieza; consulte propiedad del tiempo de ejecución
Páginas mixtas, enfoque, ventanas emergentes o resultados de IU tardíos	Contexto de prueba GPUI existente y entidad de característica; el IME nativo, la ventana y el comportamiento de GPU aún requieren validación del host
Adaptador de plugin, MCP o CLI	Despacho real y datos devueltos, autoridad, identidad de destino o efecto secundario; evite reproducir solo el ayudante de dominio
Redacción y vida útil de credenciales	Entrada de secreto sintético a través del límite de salida o propiedad relevante; consulte datos sensibles
Scripts de empaquetado y repositorio	Pruebas de script existentes o el contrato de ejecución en seco real seleccionado por la matriz de verificación

Para una prueba de nodo compartido, cerrar un terminal debería dejar otro consumidor real utilizable. Para el manejo de resultados obsoletos, entregue una finalización antigua después de que el propietario haya cambiado. Use fixtures existentes y sincronización controlada por eventos; los retrasos arbitrarios y los reintentos adicionales no establecen estas condiciones.

Validar y Finalizar

Termine las ediciones relevantes de fuente/prueba antes de iniciar su ejecución de prueba. Mantenga el checkout estable durante esa ejecución.

1. Ejecute la prueba o módulo enfocado, por ejemplo cargo test -p <crate> <test_filter>. Use el objetivo y la plataforma que realmente lo poseen; las pruebas de escritorio están en el destino binario oxideterm-native de oxideterm-gpui-app. El agente remoto independiente usa --manifest-path agent/Cargo.toml.
2. Lea el resultado y verifique que las pruebas previstas realmente se ejecutaron. Un comando exitoso con cero pruebas coincidentes no es una prueba. Después de una eliminación o movimiento, ejecute la cobertura restante nombrada y cualquier verificación de integración afectada distinta.
3. Ejecute cargo fmt --check y git diff --check para ediciones de Rust. Agregue comprobaciones de crate, pruebas de script, auditoría de configuración regional o flujos de trabajo manuales según la matriz de verificación. Reutilice los resultados hasta que los cambios relevantes o la nueva evidencia los invaliden.
4. Revise la diferencia final y el estado. Verifique que ningún comportamiento único haya desaparecido, que no se hayan debilitado las aserciones para ocultar una falla del producto y que no se haya modificado ningún trabajo no relacionado.

Use la mutación deliberada solo cuando sea necesario para resolver una duda concreta sobre una aserción. Manténgala aislada del trabajo del usuario, restaure la fuente exacta después y no la requiera para cada prueba. Las auditorías de todo el subsistema deben reconciliar los casos eliminados con sus pruebas restantes nombradas antes de ejecutar los conjuntos afectados finales.

Reporte la decisión, el comportamiento aún protegido, las comprobaciones realmente ejecutadas y cualquier límite no verificado material. Explique la cobertura eliminada cuando ocurrió la eliminación. Deténgase cuando el alcance solicitado esté completo; no amplíe la auditoría para cumplir un objetivo de recuento o reducción.

Fuente

Adaptado de los principios de valor de prueba y evidencia en test-audit de OpenClaw y guía de campaña. La ejecución, propiedad y validación aquí siguen las reglas del repositorio de OxideTerm.