Personalizzazione dell'analisi code coverage
Per impostazione predefinita, lo strumento Code Coverage di Visual Studio analizza tutti gli assembly della soluzione (.exe/.dll) caricati durante gli unit test.È consigliabile mantenere questa impostazione predefinita in quanto funziona bene nella maggior parte dei casi.Per altre informazioni, vedere Utilizzo di code coverage per determinare la quantità di codice testato.
Prima di personalizzare il comportamento del code coverage, considerare alcune alternative:
Si vuole escludere il codice di test dai risultati del code coverage e includere solo il codice dell'applicazione.
Aggiungere l'attributo ExcludeFromCodeCoverage alla classe di test.
Si vogliono includere assembly che non fanno parte della soluzione.
Ottenere i file con estensione pdb per questi assembly e copiarli nella stessa cartella dei file con estensione dll dell'assembly.
Per personalizzare il comportamento del code coverage, copiare l'esempio alla fine di questo argomento e aggiungerlo alla soluzione mediante l'estensione di file runsettings.Modificarlo secondo le proprie esigenze, quindi dal menu Test scegliere Impostazioni test e Seleziona impostazioni test.Nella parte restante di questo argomento questa procedura viene descritta più dettagliatamente.
Le impostazioni avanzate di code coverage vengono specificate in un file con estensione runsettings.Si tratta del file di configurazione usato dagli strumenti di unit test.Si consiglia di copiare l'esempio alla fine di questo argomento e di modificarlo per soddisfare le proprie esigenze.
Per personalizzare il code coverage, sarà necessario aggiungere un file con estensione runsettings alla soluzione:
Aggiungere un file XML come elemento della soluzione con l'estensione runsettings:
In Esplora soluzioni, dal menu di scelta rapida della soluzione, scegliere Aggiungi, Nuovo elemento e selezionare File XML.Salvare il file con un nome che termina come CodeCoverage.runsettings
Aggiungere il contenuto fornito nell'esempio alla fine di questo argomento, quindi personalizzarlo secondo le proprie esigenze come descritto nelle sezioni seguenti.
Dal menu Test scegliere Impostazioni test, Seleziona file di impostazioni test e selezionare il file.
Quando si esegue Analizza code coverage, questo file con estensione .runsettings controllerà il comportamento.Non dimenticare che è necessario ripetere l'esecuzione del code coverage: i risultati del code coverage e la colorazione del codice precedenti non vengono automaticamente nascosti quando si eseguono i test o si aggiorna il codice.
Per attivare e disattivare le impostazioni personalizzate, deselezionare o selezionare il file nel menu Test, Impostazioni test.
Altri aspetti degli unit test possono essere configurati nello stesso file con estensione runsettings.Per altre informazioni, vedere Verifica del codice tramite unit test.
Il code coverage richiede che siano presenti i simboli (file con estensione pdb) per gli assembly.Per gli assembly compilati dalla soluzione, i file di simboli sono solitamente presenti accanto ai file binari e il code coverage viene eseguito automaticamente.In alcuni casi invece è consigliabile includere assembly a cui si fa riferimento nell'analisi del code coverage.In tali casi, i file con estensione pdb non possono essere adiacenti ai binari, ma è possibile specificare il percorso di ricerca dei simboli nel file con estensione runsettings.
<SymbolSearchPaths>
<Path>\\mybuildshare\builds\ProjectX</Path>
<!--More paths if required-->
</SymbolSearchPaths>
Attenzione |
---|
La risoluzione dei simboli può richiedere tempo, in particolare quando si usa un percorso di file remoto con molti assembly.Di conseguenza, si consiglia di copiare i file remoti con estensione pdb nello stesso percorso locale dei file binari (.dll ed .exe). |
È possibile escludere gli assembly specificati dall'analisi code coverage.Ad esempio:
<ModulePaths>
<Exclude>
<ModulePath>Fabrikam.Math.UnitTest.dll</ModulePath>
<!-- Add more ModulePath nodes here. -->
</Exclude>
</ModulePaths>
In alternativa, è possibile specificare gli assembly che devono essere inclusi.Questo approccio presenta lo svantaggio che quando si aggiungono più assembly alla soluzione, è necessario tenere a mente che occorre aggiungerli anche all'elenco:
<ModulePaths>
<Include>
<ModulePath>Fabrikam.Math.dll</ModulePath>
<!-- Add more ModulePath nodes here. -->
</Include>
</ModulePaths>
Se <Include> è vuoto, l'elaborazione del code coverage include tutti gli assembly (file con estensione dll ed exe) caricati e che dispongono dei file .pdb, ad eccezione degli elementi che soddisfano una clausola di un elenco <Exclude>.
Include viene elaborato prima Exclude.
Includere ed escludere i nodi che usano le espressioni regolari.Per altre informazioni, vedere Utilizzo delle espressioni regolari in Visual Studio.Le espressioni regolari non equivalgono ai caratteri jolly.In particolare:
.* corrisponde ad una stringa composta da qualsiasi carattere
\. corrisponde ad un punto "."
\( \) corrisponde alle parentesi "( )"
\\ corrisponde al delimitatore del percorso di file "\"
^ corrisponde all'inizio della stringa
$ corrisponde alla fine della stringa
Tutte le corrispondenze fanno distinzione tra maiuscole e minuscole.
Ad esempio:
<ModulePaths>
<Include>
<!-- Include all loaded .dll assemblies (but not .exe assemblies): -->
<ModulePath>.*\.dll$</ModulePath>
</Include>
<Exclude>
<!-- But exclude some assemblies: -->
<ModulePath>.*\\Fabrikam\.MyTests1\.dll$</ModulePath>
<!-- Exclude all file paths that contain "Temp": -->
<ModulePath>.*Temp.*</ModulePath>
</Exclude>
</ModulePaths>
Attenzione |
---|
Se è presente un errore in un'espressione regolare, come un carattere senza codice di escape e parentesi non corrispondenti, l'analisi di code coverage non funzionerà. |
Vedere l'esempio alla fine di questo argomento.
ModulePath: assembly specificati per percorso del file di assembly.
CompanyName: assembly corrispondenti per attributo della società.
PublicKeyToken: assembly firmati corrispondenti per token di chiave pubblica.Ad esempio per soddisfare tutti i componenti e le estensioni di Visual Studio, usare <PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken>.
Source: elementi corrispondenti per nome del percorso del file di origine in cui sono definiti.
Attribute: elementi corrispondenti ai quali è connesso un particolare attributo.Specificare il nome completo dell'attributo, includendo "Attribute" alla fine del nome.
Function: procedure, funzioni o metodi corrispondenti per nome completo.
Corrispondenza di un nome di funzione
L'espressione regolare deve corrispondere al nome completo della funzione, incluso lo spazio dei nomi, il nome della classe, il nome del metodo e l'elenco parametri.Di seguito è riportato un esempio:
C# o Visual Basic: Fabrikam.Math.LocalMath.SquareRoot(double)
C++: Fabrikam::Math::LocalMath::SquareRoot(double)
<Functions>
<Include>
<!-- Include methods in the Fabrikam namespace: -->
<Function>^Fabrikam\..*</Function>
<!-- Include all methods named EqualTo: -->
<Function>.*.\EqualTo\(.*</Function>
</Include>
<Exclude>
<!-- Exclude methods in a class or namespace named UnitTest: -->
<Function>.*\.UnitTest\..*</Function>
</Exclude>
</Functions>
Scegliere Test, Impostazioni test, Seleziona file di impostazioni test e selezionare il file con estensione runsettings.Il file viene visualizzato nel menu Impostazioni test ed è possibile selezionarlo o annullare l'operazione.Quando viene selezionato, il file con estensione runsettings viene applicato ogni volta che si usa Analizza code coverage.
Per eseguire un test dalla riga di comando usare vstest.console.exe.Il file di impostazioni è un parametro di questa utilità.Per altre informazioni, vedere Uso di VSTest.console dalla riga di comando.
Avviare il prompt dei comandi di Visual Studio Developer:
In Windows scegliere Start, Tutti i programmi, Microsoft Visual Studio, Strumenti di Visual Studio, Prompt dei comandi per gli sviluppatori.
Eseguire:
vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettings
È possibile ottenere dati di code coverage da Team Build.
Assicurarsi che il file con estensione runsettings sia selezionato.
In Team Explorer aprire Compilazioni e aggiungere o modificare una definizione di compilazione.
Nella pagina Processo espandere Test automatizzati, Origine test, Impostazioni esecuzione test.Selezionare il file .runsettings.
Viene visualizzato Assembly di test anziché Origine test.Quando si prova ad impostare il campo Impostazioni esecuzione test, è possibile selezionare solo file con estensione testsettings.
In Test automatizzati, selezionare Assembly di test e scegliere [...] alla fine della riga.Nella finestra di dialogo Aggiungi/Modifica esecuzione dei test, impostare Test Runner su Visual Studio Test Runner.
I risultati vengono visualizzati nella sezione di riepilogo del report di compilazione.
Copiare questo codice e modificarlo secondo le proprie esigenze.Questa è l'impostazione predefinita del file con estensione runsettings.
Per altri utilizzi del file con estensione runsettings, vedere la pagina relativa alla Configurazione di unit test mediante un file .runsettings.
<?xml version="1.0" encoding="utf-8"?>
<!-- File name extension must be .runsettings -->
<RunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<!--
Additional paths to search for .pdb (symbol) files. Symbols must be found for modules to be instrumented.
If .pdb files are in the same folder as the .dll or .exe files, they are automatically found. Otherwise, specify them here.
Note that searching for symbols increases code coverage runtime. So keep this small and local.
-->
<!--
<SymbolSearchPaths>
<Path>C:\Users\User\Documents\Visual Studio 2012\Projects\ProjectX\bin\Debug</Path>
<Path>\\mybuildshare\builds\ProjectX</Path>
</SymbolSearchPaths>
-->
<!--
About include/exclude lists:
Empty "Include" clauses imply all; empty "Exclude" clauses imply none.
Each element in the list is a regular expression (ECMAScript syntax). See https://msdn.microsoft.com/library/2k3te2cs.aspx.
An item must first match at least one entry in the include list to be included.
Included items must then not match any entries in the exclude list to remain included.
-->
<!-- Match assembly file paths: -->
<ModulePaths>
<Include>
<ModulePath>.*\.dll$</ModulePath>
<ModulePath>.*\.exe$</ModulePath>
</Include>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
<!-- Match fully qualified names of functions: -->
<!-- (Use "\." to delimit namespaces in C# or Visual Basic, "::" in C++.) -->
<Functions>
<Exclude>
<Function>^Fabrikam\.UnitTest\..*</Function>
<Function>^std::.*</Function>
<Function>^ATL::.*</Function>
<Function>.*::__GetTestMethodInfo.*</Function>
<Function>^Microsoft::VisualStudio::CppCodeCoverageFramework::.*</Function>
<Function>^Microsoft::VisualStudio::CppUnitTestFramework::.*</Function>
</Exclude>
</Functions>
<!-- Match attributes on any code element: -->
<Attributes>
<Exclude>
<!—Don't forget "Attribute" at the end of the name -->
<Attribute>^System\.Diagnostics\.DebuggerHiddenAttribute$</Attribute>
<Attribute>^System\.Diagnostics\.DebuggerNonUserCodeAttribute$</Attribute>
<Attribute>^System\.Runtime\.CompilerServices.CompilerGeneratedAttribute$</Attribute>
<Attribute>^System\.CodeDom\.Compiler.GeneratedCodeAttribute$</Attribute>
<Attribute>^System\.Diagnostics\.CodeAnalysis.ExcludeFromCodeCoverageAttribute$</Attribute>
</Exclude>
</Attributes>
<!-- Match the path of the source files in which each method is defined: -->
<Sources>
<Exclude>
<Source>.*\\atlmfc\\.*</Source>
<Source>.*\\vctools\\.*</Source>
<Source>.*\\public\\sdk\\.*</Source>
<Source>.*\\microsoft sdks\\.*</Source>
<Source>.*\\vc\\include\\.*</Source>
</Exclude>
</Sources>
<!-- Match the company name property in the assembly: -->
<CompanyNames>
<Exclude>
<CompanyName>.*microsoft.*</CompanyName>
</Exclude>
</CompanyNames>
<!-- Match the public key token of a signed assembly: -->
<PublicKeyTokens>
<!-- Exclude Visual Studio extensions: -->
<Exclude>
<PublicKeyToken>^B77A5C561934E089$</PublicKeyToken>
<PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken>
<PublicKeyToken>^31BF3856AD364E35$</PublicKeyToken>
<PublicKeyToken>^89845DCD8080CC91$</PublicKeyToken>
<PublicKeyToken>^71E9BCE111E9429C$</PublicKeyToken>
<PublicKeyToken>^8F50407C4E9E73B6$</PublicKeyToken>
<PublicKeyToken>^E361AF139669C375$</PublicKeyToken>
</Exclude>
</PublicKeyTokens>
<!-- We recommend you do not change the following values: -->
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
Cosa si è verificato nel file con estensione testsettings usato in Visual Studio 2010?
In Visual Studio 2010 il file con estensione testsettings si applica solo agli unit test basati sul framework MSTest.In Visual Studio 2012 gli strumenti di test sono validi non solo per MSTest, ma anche altri framework come NUnit e xUnit.net.Il file con estensione testsettings non funzionerà con questi framework.Il file con estensione runsettings è progettato per personalizzare gli strumenti di test in modo da funzionare con tutti i framework di test.
Verifica del codice tramite unit test
Utilizzo di code coverage per determinare la quantità di codice testato