testgraph

testgraph é um seletor de testes de nível de jornada. Dado um diff do git, ele responde quais fluxos voltados para o usuário uma alteração poderia ter quebrado e em que ordem eles devem ser testados, retornando uma lista curta e ranqueada em vez de uma diretiva para executar tudo novamente. Ele deliberadamente não controla navegadores, gera testes ou se autocura; seu trabalho declarado é a camada acima dos drivers existentes, ou seja, decidir o que vale a pena testar. Como funciona Um registro de jornadas nomeia cada jornada de usuário e seus símbolos de entrada, como manipuladores de rota ou uma varredura de agendador. O módulo propose esboça um registro para um novo repositório escaneando decoradores de rota Python e convenções do Next.js contra o índice, marcando-o como aprovado falso até que um humano o leia, para que um registro não aprovado execute ruidosamente, mas nunca silenciosamente. Para um diff, o testgraph mapeia intervalos de linhas alteradas para os símbolos que as possuem, as sementes; percorre o grafo de arestas do CodeGraph em reverso, transitivamente, para cada símbolo que depende de uma semente, o conjunto impactado; e relata as jornadas cujos símbolos de entrada caem nesse conjunto, ranqueadas por fan-in, cada uma carregando a confiança do caminho de aresta mais forte que a alcançou. A confiança é o máximo sobre caminhos do mínimo sobre arestas, portanto, uma cadeia é tão confiável quanto seu salto mais fraco, enquanto uma rota sólida é suficiente. Uma jornada alcançada apenas através de arestas fracas ou sintetizadas é sinalizada para verificação manual em vez de ser silenciosamente confiada, e nunca é removida da seleção. A ferramenta prioriza o recall: ela prefere a superseleção a descartar silenciosamente uma jornada que uma alteração realmente afetou. Antes de responder, uma guarda de integridade recusa-se a executar a partir de um índice CodeGraph corrompido ou obsoleto, pois um grafo errado produz uma resposta confiantemente errada. A resolução do registro pesquisa, vencendo o primeiro acerto: uma variável de ambiente de escape, depois um diretório .testgraph/journeys dentro do repositório, descrito como o local recomendado, e então um diretório journeys ao lado do pacote no checkout do próprio projeto. Um registro é correspondido por seu alvo autodeclarado em vez de seu nome de arquivo, em cada local, e um copiado de outro projeto e deixado sem edição é recusado. Pré-requisitos e instalação Python 3.11 ou mais novo usando apenas a biblioteca padrão, sem dependências de terceiros; git para entrada de diff; e um repositório alvo com um índice CodeGraph produzido por codegraph init. Instale via PyPI com pip install testgraph. O wheel envia apenas o pacote, enquanto o harness de medição e os registros de dogfood residem no repositório. CLI e MCP Os pontos de entrada de linha de comando incluem select, com saída legível para humanos ou JSON destinada a um gate de CI ou outro agente; export, que escreve um mapa de jornada estático que um agente lê pré-commit; propose; record; e um modo de sumário. O servidor MCP stdio expõe duas ferramentas, testgraph_impact e testgraph_journeys, e é registrado por repositório. Ele utiliza apenas a stdlib e importa os módulos de análise preguiçosamente, portanto, um servidor ocioso não carregou o sqlite3, não mantém conexão com banco de dados nem mantém índice em memória. O README relata 15,2 MB de RSS medidos após um handshake completo, contra 62 a 69 MB para um servidor MCP SDK Python típico. Conexões e o livro-razão hooks/install.sh instala um hook de pré-push em cada repositório com um registro aprovado, para que cada push imprima as jornadas que poderia ter quebrado. O hook executa codegraph sync primeiro, porque as sementes vêm de intervalos de linhas e um índice construído antes do código ter se movido resolveria um diff contra spans obsoletos; se os bytes de um arquivo alterado ainda discordarem da cópia indexada, a resposta degrada e nomeia o arquivo. O hook nunca falha um push, com todos os caminhos saindo com zero, e pode ser desativado por repositório com uma configuração de git config ou removido com uma flag de desinstalação. Cada execução anexa uma linha de seleção a um livro-razão JSONL; o comando record escreve a outra metade, o que a execução de uma jornada encontrou, para que os dois unidos por repositório e commit possam contar uma jornada que falhou em um commit cuja seleção não a nomeou, descrito como uma subseleção silenciosa. Status É descrito como um spike de fase-1 mais caminhos ponderados por confiança, funcionando e validado em um alvo de dogfood: recall 1.00 em cinco commits rotulados manualmente com precisão média de 0.68, e 1.00 em vinte locais de mutação semeados pontuados contra um oráculo AST independente, com a guarda de integridade testada e esquema fixado. O escopo é esse alvo único, analisando arquivos de backend e frontend com jornadas registradas em pontos de entrada de backend. O README também registra que medições posteriores em dois repositórios sem registro falsificaram a reivindicação de economia anterior: com 23 jornadas, um repositório deu um histograma de zero jornadas para 38 commits e 23 para 2 commits, e com 207 jornadas, outro evitou apenas 54,1 por cento das execuções de jornada quando commits que não tocavam nenhuma superfície registrada foram excluídos, portanto, os números de seleção devem ser lidos como um piso de acoplamento em vez de uma promessa de economia. A mesma medição confirmou o ranqueamento, com uma seleção de registro completo falso-positiva sinalizada para verificação manual com confiança 0.3, enquanto um raio de impacto genuíno e grande retornou limpo com 0.9.