Impatto del test per i repository TFVC parzialmente mappati in TFS/Azure DevOps Services
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Test Impact Analysis (TIA) fa parte dell'attività VSTest a partire dalla versione 2 dell'attività. Questa funzionalità consente di velocizzare il ciclo DevOps consentendo di eseguire solo test pertinenti per una compilazione. In effetti, si finisce per eseguire test che sono interessati dalle modifiche in ingresso e non dall'intero gruppo di test. Per altre informazioni sull'analisi dell'impatto dei test, vedere Velocizzare i test usando l'analisi dell'impatto dei test .NET.For more information about Test Impact Analysis, see Speed up testing by using Test Impact Analysis (TIA).
Oltre a supportare GitHub e Git in Azure DevOps, TIA supporta anche TFVC. Questo articolo descrive una limitazione nota di TIA nelle pipeline di compilazione/versione basate su TFVC e una soluzione alternativa per superare questa limitazione.
Problema con repository TFVC parzialmente mappati
Il funzionamento di TIA consiste nella raccolta di dati sui file toccati da un metodo di test durante la prima esecuzione, detta anche esecuzione della riga di base. L'agente di raccolta che raccoglie questi dati ha visibilità solo del repository incluso nel computer agente. Con le pipeline basate su TFVC, è possibile integrare repository parziali. Si consideri, ad esempio, un repository con la struttura seguente.
Nella pipeline di compilazione/versione viene ora visualizzato il riquadro Recupera origini in Processo , come illustrato nell'esempio seguente.
Selezionare Recupera origini e verranno visualizzate le opzioni nel pannello destro per eseguire parzialmente il mapping del repository.
Se si integra l'intero repository, come illustrato nell'esempio precedente, TIA continua a funzionare correttamente, ma se si integra parzialmente, come illustrato nell'esempio seguente, TIA non riesce a trovare i test interessati.
Quando un repository TFVC è parzialmente incluso, TIA non riesce a trovare i test interessati perché l'agente di raccolta è in grado di raccogliere le modifiche solo per il repository parzialmente incluso nell'agente e non ha visibilità dell'intero percorso. Quando una modifica del codice passa dal server, fornisce l'intero percorso e il tentativo di corrispondenza con il percorso mappato ha esito negativo.
Soluzione alternativa
Per risolvere questo problema, è possibile eseguire il mapping del repository parziale alla struttura di codice completa nel server, in modo che il percorso completo dei file nell'integrazione locale corrisponda al percorso completo del server. A tale scopo, è possibile specificare un percorso locale corrispondente al percorso del server, come illustrato nell'esempio seguente.
In questo modo, il percorso del server corrisponde al percorso raccolto dall'agente di raccolta e i test interessati vengono elencati correttamente.