Impacto de teste para repositórios TFVC parcialmente mapeados no TFS/Azure DevOps Services
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
A TIA (Análise de Impacto de Teste) fez parte da tarefa VSTest começando com a versão 2 da tarefa. Esse recurso ajuda a acelerar o ciclo de DevOps, ajudando você a executar apenas testes relevantes para um build. Efetivamente, você acaba executando testes que são afetados por alterações de entrada e não por todo o conjunto de testes. Para obter mais informações sobre a Análise de Impacto de Teste, consulte Acelerar o teste usando a TIA (Análise de Impacto de Teste).
Além de dar suporte ao GitHub e ao Git no Azure DevOps, a TIA também dá suporte ao TFVC. Este artigo descreve uma limitação conhecida sobre a TIA em pipelines de build/lançamento com base no TFVC e uma solução alternativa para superar essa limitação.
Problema com repositórios TFVC parcialmente mapeados
A maneira como a TIA funciona é coletando dados nos arquivos que um método de teste toca durante sua primeira execução, também chamada de execução de linha base. O coletor que coleta esses dados tem visibilidade apenas do repositório inscrito no computador do agente. Com pipelines baseados em TFVC, você obtém uma opção para inscrever repositórios parciais. Por exemplo, considere um repositório que tenha a estrutura a seguir.
Agora, no pipeline de build/lançamento, você vê o bloco Obter fontes em Processo, conforme mostrado no exemplo a seguir.
Selecione Obter fontes e você verá opções na folha direita para mapear parcialmente o repositório.
Se você inscrever o repositório inteiro, conforme mostrado no exemplo anterior, a TIA continuará funcionando bem, mas se você inscrevê-lo parcialmente, conforme mostrado no exemplo a seguir, a TIA não conseguirá encontrar os testes afetados.
Quando um repositório TFVC é parcialmente inscrito, a TIA não consegue localizar os testes afetados porque o coletor é capaz de coletar apenas as alterações do repositório parcialmente inscrito no agente e não tem visibilidade do caminho inteiro. Quando uma alteração de código flui do servidor, ela fornece o caminho inteiro e a tentativa de correspondência com o caminho mapeado falha.
Solução alternativa
Para contornar esse problema, você pode mapear seu repositório parcial para a estrutura de código completa no servidor, para que o caminho completo dos arquivos em sua inscrição local corresponda ao caminho completo do servidor. Para fazer isso, você pode especificar um Caminho Local que corresponda ao caminho do servidor, conforme mostrado no exemplo a seguir.
Isso garante que o caminho do servidor corresponda ao caminho coletado pelo coletor e que os testes afetados estejam listados corretamente.