testgraph

testgraph es un selector de pruebas a nivel de trayecto (journey-level). Dado un git diff, responde qué flujos orientados al usuario podría haber roto un cambio y en qué orden deben probarse, devolviendo una lista corta y clasificada en lugar de una directiva para volver a ejecutar todo. Deliberadamente no controla navegadores, no genera pruebas ni se auto-repara; su función declarada es la capa superior a los controladores existentes, concretamente decidir qué merece ser probado. Cómo funciona Un registro de trayectos nombra cada trayecto de usuario y sus símbolos de entrada, como controladores de rutas o un barrido de programador. El módulo propose redacta un registro para un nuevo repositorio escaneando decoradores de ruta de Python y convenciones de Next.js frente al índice, marcándolo como approved false hasta que un humano lo lea, de modo que un registro no aprobado se ejecute ruidosamente pero nunca en silencio. Para un diff, testgraph mapea los rangos de líneas cambiadas a los símbolos que las poseen, las semillas; recorre el grafo de aristas de CodeGraph en reversa, transitivamente, hasta cada símbolo que dependa de una semilla, el conjunto impactado; e informa los trayectos cuyos símbolos de entrada caen en ese conjunto, clasificados por fan-in, cada uno llevando la confianza de la ruta de arista más fuerte que lo alcanzó. La confianza es el máximo sobre las rutas del mínimo sobre las aristas, por lo que una cadena es tan confiable como su salto más débil, mientras que una sola ruta sólida es suficiente. Un trayecto alcanzado solo a través de aristas débiles o sintetizadas se marca para verificación manual en lugar de confiar ciegamente en él, y nunca se elimina de la selección. La herramienta prioriza la exhaustividad (recall-first): prefiere la sobre-selección a omitir silenciosamente un trayecto que un cambio realmente afectó. Antes de responder, un guardián de integridad se niega a ejecutarse sobre un índice de CodeGraph corrupto o desactualizado, ya que un grafo incorrecto produce una respuesta errónea con confianza. La resolución del registro busca, ganando el primer acierto: una variable de entorno de escape, luego un directorio .testgraph/journeys dentro del repositorio (ubicación recomendada), y luego un directorio journeys junto al paquete en el checkout del proyecto. Un registro se empareja por su objetivo autodeclarado en lugar de su nombre de archivo, en cualquier ubicación, y se rechaza aquel que haya sido copiado de otro proyecto y dejado sin editar. Prerrequisitos e instalación Python 3.11 o posterior utilizando únicamente la biblioteca estándar, sin dependencias de terceros; git para la entrada de diff; y un repositorio objetivo con un índice de CodeGraph producido por codegraph init. Instalación desde PyPI con pip install testgraph. El wheel distribuye solo el paquete, mientras que el arnés de medición y los registros de dogfood residen en el repositorio. CLI y MCP Los puntos de entrada de la línea de comandos incluyen select, con salida legible para humanos o JSON destinada a una puerta de CI u otro agente; export, que escribe un mapa de trayectos estático que un agente lee antes del commit; propose; record; y un modo de resumen. El servidor MCP stdio expone dos herramientas, testgraph_impact y testgraph_journeys, y se registra por repositorio. Es solo stdlib e importa los módulos de análisis de forma perezosa, por lo que un servidor inactivo no ha cargado sqlite3, no mantiene ninguna conexión a la base de datos ni guarda ningún índice en memoria. El README reporta 15.2 MB de RSS medidos después de un saludo completo, frente a los 62 a 69 MB de un servidor típico de Python MCP SDK. Cableado y el libro mayor hooks/install.sh instala un hook de pre-push en cada repositorio con un registro aprobado, por lo que cada push imprime los trayectos que podría haber roto. El hook ejecuta primero codegraph sync, porque las semillas provienen de rangos de líneas y un índice construido antes de que el código se moviera resolvería un diff contra tramos desactualizados; si los bytes de un archivo cambiado aún discrepan de la copia indexada, la respuesta se degrada y nombra el archivo. El hook nunca falla un push, con cada ruta saliendo con cero, y puede desactivarse por repositorio con un ajuste de git config o eliminarse con una bandera de uninstall. Cada ejecución añade una fila de selección a un libro mayor JSONL; el comando record escribe la otra mitad, lo que encontró la ejecución de un trayecto, por lo que los dos unidos por repositorio y commit pueden contar un trayecto que falló en un commit cuya selección no lo nombró, descrito como una sub-selección silenciosa. Estado Se describe como un spike de fase 1 más rutas ponderadas por confianza, funcionando y validado en un objetivo de dogfood: recall 1.00 en cinco commits etiquetados a mano con una precisión media de 0.68, y 1.00 en veinte sitios de mutación sembrados puntuados contra un oráculo AST independiente, con el guardián de integridad probado y el esquema anclado. El alcance es ese único objetivo, analizando archivos de backend y frontend con trayectos registrados en puntos de entrada de backend. El README también registra que mediciones posteriores en dos repositorios sin registro falsificaron la afirmación anterior de ahorro: con 23 trayectos, un repositorio dio un histograma de cero trayectos para 38 commits y 23 para 2 commits, y con 207 trayectos, otro evitó solo el 54.1 por ciento de las ejecuciones de trayectos una vez que se excluyeron los commits que no tocaban ninguna superficie registrada, por lo que los números de selección deben leerse como un suelo de acoplamiento en lugar de una promesa de ahorro. La misma medición confirmó la clasificación, con una selección de registro completo (falso positivo) marcada para verificación manual con una confianza de 0.3, mientras que un radio de impacto genuinamente grande regresó limpio con 0.9.