test dotnet con Microsoft.Testing.Platform (MTP)

Questo articolo si applica a: ✔️ .NET 10 SDK e versioni successive

Nome

dotnet test : .NET driver di test usato per eseguire unit test con MTP.

Synopsis

dotnet test
    [<PROJECT_OR_TRAVERSAL_PATH>]
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>]
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [--config-file <CONFIG_FILE>]
    [--results-directory <RESULTS_DIRECTORY>]
    [--results-directory-layout <flat|per-module>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <NUMBER>]
    [--maximum-failed-tests <NUMBER>]
    [--timeout <DURATION>]
    [-e|--environment <NAME="VALUE">]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--use-current-runtime|--ucr]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-dependencies]
    [--no-restore]
    [--nologo|--no-logo|--no-banner]
    [--no-ansi]
    [--no-progress]
    [--no-artifact-post-processing]
    [--output <VERBOSITY_LEVEL>]
    [--show-test-results <OUTCOME>]
    [--list-tests [text|json]]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [--device <DEVICE_ID>]
    [--list-devices]
    [--collect-test-map]
    [--affected-tests]
    [<args>...]

dotnet test -h|--help

Description

Con MTP, dotnet test funziona più velocemente rispetto a vsTest. Gli argomenti correlati al test non sono più fissi, perché sono associati alle estensioni registrate nei project di test. MTP supporta inoltre un filtro globbing durante l'esecuzione dei test. Per altre informazioni, vedere MTP.

Importante

Le opzioni specifiche dell'estensione non sono integrate in MTP. Ogni applicazione di test di destinazione deve registrare l'estensione che fornisce un'opzione. Aggiungere direttamente il pacchetto NuGet dell'estensione oppure usare una configurazione o un profilo dell'SDK di test che include il pacchetto. In caso contrario, l'esecuzione del test non riesce con il codice di uscita 5 perché l'opzione non è riconosciuta. Eseguire dotnet test --help per visualizzare le opzioni disponibili per le applicazioni di test selezionate e vedere Opzioni di estensione per scenario per trovare il pacchetto per un'opzione.

Avvertimento

Quando MTP è consenso esplicito tramite global.json, dotnet test prevede che tutti i progetti di test usino MTP. Si tratta di un errore se uno dei progetti di test usa VSTest.

Requisiti di versione

La modalità MTP di dotnet test richiede .NET 10 SDK e MTP 1.7 o versione successiva. Le opzioni aggiunte dopo .NET 10 hanno requisiti di versione dell'SDK individuali nelle sezioni seguenti. Alcune opzioni richiedono anche un pacchetto MTP più recente perché l'SDK coordina l'esecuzione completa mentre ogni applicazione di test implementa la funzionalità corrispondente.

Ripristino implicito

Non è necessario eseguire dotnet restore perché viene eseguito in modo implicito da tutti i comandi che richiedono un ripristino, ad esempio dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish e dotnet pack. Per disabilitare il ripristino implicito, usare l'opzione --no-restore.

Il comando dotnet restore è ancora utile in alcuni scenari in cui il ripristino esplicito ha senso, ad esempio compilazioni di integrazione non significative in Azure DevOps Services o nei sistemi di compilazione che devono controllare in modo esplicito quando si verifica il ripristino.

Per informazioni su come gestire i feed NuGet, vedere la dotnet restore documentazione.

Options

Annotazioni

È possibile usare una sola delle opzioni seguenti alla volta: --project, --solution o --test-modules. Queste opzioni non possono essere combinate. Inoltre, quando si usa --test-modules, non è possibile specificare --arch, , --configuration--device, --framework, --list-devices--os, , --runtimeo --use-current-runtime. Queste opzioni richiedono la valutazione del progetto o non sono pertinenti per un modulo già compilato.

  • PROJECT_OR_TRAVERSAL_PATH

    Specifica un progetto o un progetto di attraversamento da eseguire. A partire da .NET 11 Preview 7, dotnet test supporta Microsoft.Build.Traversal progetti, ad esempio dirs.proj, ed esegue in modo ricorsivo i progetti di test a cui si fa riferimento.

    A partire da .NET 12 Preview 1, l'argomento può anche identificare un'app di test MTP basata su file C#. Le app di test basate su file non supportano --device.

  • --project <PROJECT_PATH>

    Specifica il percorso del file project da eseguire (nome della cartella o percorso completo). Se non specificato, per impostazione predefinita il percorso corrisponde alla directory corrente.

  • --solution <SOLUTION_PATH>

    Specifica il percorso del file della soluzione da eseguire (nome della cartella o percorso completo). Se non specificato, per impostazione predefinita il percorso corrisponde alla directory corrente.

  • --test-modules <EXPRESSION>

    Filtra i moduli di test usando il globbing dei file. Vengono eseguiti solo i test appartenenti a tali moduli di test. A partire da .NET 11 Preview 6, anteporre un modello a ! per escludere i moduli corrispondenti. Separare più modelli con punto e virgola; gli spazi vuoti intorno a ogni modello vengono ignorati.

  • --root-directory <ROOT_PATH>

    Specifica la directory radice dell'opzione --test-modules. Può essere usato solo con l'opzione --test-modules.

  • --max-parallel-test-modules <NUMBER>

    Specifica il numero massimo di moduli di test che possono essere eseguiti in parallelo. Il valore predefinito è Environment.ProcessorCount.

  • --config-file <CONFIG_FILE>

    Specifica il file di configurazione da usare per l'esecuzione di test. Se viene specificato un percorso relativo, viene convertito in un percorso assoluto basato sulla directory corrente. Per altre informazioni sulle impostazioni del file di configurazione, vedere testconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

    Specifica la directory in cui vengono archiviati i risultati dei test. Se la directory non esiste, viene creata. Se viene specificato un percorso relativo, viene convertito in un percorso assoluto basato sulla directory corrente.

  • --results-directory-layout <flat|per-module>

    Specifica il modo in cui un'esecuzione multimodulo organizza i file nella directory dei risultati. Il valore predefinito, flat, scrive tutti i risultati nella stessa directory. per-module scrive i risultati di ogni modulo in <project>/<target-framework>_<runtime-or-architecture>, che impedisce ai report con lo stesso nome di file di sovrascrivere l'uno all'altro.

    Disponibile a partire da .NET 11 RC 1.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

    Specifica la directory in cui è archiviato l'output di diagnostica. Se la directory non esiste, viene creata. Se viene specificato un percorso relativo, viene convertito in un percorso assoluto basato sulla directory corrente.

  • --minimum-expected-tests <NUMBER>

    Specifica un numero minimo positivo di test per l'intera esecuzione. Se il numero di test aggregato è inferiore al minimo specificato, l'esecuzione del test ha esito negativo con codice di uscita 9. Il conteggio globale include test ignorati. Per altre informazioni sui codici di uscita, vedere Codici di uscita MTP.

    Poiché questa opzione viene visualizzata prima --di , è un'opzione globale (intera). Per richiedere un minimo per ogni modulo di test, passare invece l'opzione dopo -- in modo che venga inoltrata a ogni modulo di test. Per altre informazioni, vedere Valori minimi per l'intera esecuzione e per modulo.

    Annotazioni

    Il minimo globale richiede .NET 10 SDK (10.0.100) o una versione successiva.

  • --maximum-failed-tests <NUMBER>

    Arresta l'esecuzione completa dopo che raggiunge il numero specificato di test non riusciti, con errori, timeout o annullati. L'esecuzione viene chiusa con il codice 13.

    Disponibile a partire da .NET 11 Preview 7 e richiede MTP 2.4 o versione successiva.

  • --timeout <DURATION>

    Arresta l'esecuzione completa dopo la durata specificata mentre è in esecuzione almeno un'applicazione di test. Specificare un numero positivo seguito da un'unità, ad esempio 500ms, 90s, 2h10m, o 1d. Un'esecuzione di timeout viene chiusa con il codice 3.

    Disponibile a partire da .NET 11 Preview 7 e richiede MTP 2.4 o versione successiva.

  • -e|--environment <NAME="VALUE">

    Imposta una variabile di ambiente per il processo di test. Specificare l'opzione più volte per impostare più variabili. I valori della riga di comando sostituiscono i valori di un profilo di avvio.

    Usare .NET SDK 10.0.110 o versione successiva quando non esiste alcun profilo di avvio o quando si specifica --no-launch-profile; le versioni precedenti .NET 10 SDK possono ignorare le variabili in questi casi. A partire da .NET 11 Preview 7, le variabili passano anche alle destinazioni di compilazione, selezione del dispositivo, distribuzione e argomenti di esecuzione.

  • -a|--arch <ARCHITECTURE>

    Specifica l'architettura di destinazione. Si tratta di una sintassi abbreviata per l'impostazione dell'identificatore di runtime (RID), in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un computer win-x64, specificando --arch x86 si imposta il RID su win-x86. Se si usa questa opzione, non usare l'opzione -r|--runtime. Disponibile a partire da .NET 6 Preview 7.

  • --artifacts-path <ARTIFACTS_DIR>

    Tutti i file di output di compilazione del comando eseguito verranno inseriti nelle sottocartelle nel percorso specificato, separati dal progetto. Per altre informazioni, vedere layout di output artefatti. Questa opzione e il valore fornito devono essere a catena in modo esplicito in qualsiasi dotnet comando che dipende dall'output di un altro dotnet comando, ad esempio quando si usano dotnet build --no-restore e dotnet publish --no-build. Disponibile a partire da .NET 8 SDK.

    Disponibile per la modalità MTP a partire da .NET 11.

  • -c|--configuration <CONFIGURATION>

    Definisce la configurazione di compilazione. Il valore predefinito per la maggior parte dei progetti è Debug, ma è possibile eseguire l'override delle impostazioni di configurazione della compilazione nel project.

  • -f|--framework <FRAMEWORK>

    Moniker framework di destinazione (TFM) del framework di destinazione per cui eseguire i test. Il framework di destinazione deve essere specificato anche nel file di project.

  • --os <OS>

    Specifica il sistema operativo di destinazione. Si tratta di una sintassi abbreviata per l'impostazione dell'identificatore di runtime (RID), in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un computer win-x64, specificando --os linux si imposta il RID su linux-x64. Se si usa questa opzione, non usare l'opzione -r|--runtime. Disponibile dal .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Runtime di destinazione per cui eseguire i test.

    Modulo breve -r disponibile a partire da .NET SDK 7.

    Annotazioni

    L'esecuzione di test per una soluzione con una proprietà globale RuntimeIdentifier (in modo esplicito o tramite --arch, --runtimeo --os) non è supportata. Impostare RuntimeIdentifier su un singolo livello di project.

  • --use-current-runtime|--ucr

    Usa il runtime corrente come runtime di destinazione durante il ripristino e la compilazione.

    Disponibile a partire da .NET 11 Preview 6. Non è possibile combinare questa opzione con --test-modules.

  • -v|--verbosity <LEVEL>

    Imposta il livello di dettaglio del comando. I valori consentiti sono q[uiet], m[inimal], n[ormal], d[etailed] e diag[nostic]. Per altre informazioni, vedere LoggerVerbosity.

  • --no-build

    Specifica che il project di test non viene compilato prima dell'esecuzione. Imposta anche in modo implicito il flag --no-restore.

  • --no-dependencies

    Ignora la compilazione di riferimenti da progetto a progetto.

    Disponibile a partire da .NET 11 Preview 6.

  • --no-restore

    Specifica che un ripristino implicito non viene eseguito durante l'esecuzione del comando.

  • --nologo|--no-logo|--no-banner

    Elimina i banner di avvio .NET e MTP. Sono supportati anche i -nologo moduli e /nologo e la DOTNET_NOLOGO variabile di ambiente.

    Disponibile in modalità MTP a partire da .NET 11 Preview 7.

  • --no-ansi

    Disabilita l'output dei caratteri di escape ANSI sullo schermo.

  • --no-progress

    Disabilita la creazione di report sullo schermo.

  • --no-artifact-post-processing

    Disabilita la post-elaborazione degli artefatti compatibili dopo un'esecuzione multimodulo. A partire da .NET 11 RC 1 e MTP 2.4, i postprocessi di artefatti registrati possono combinare report compatibili, ad esempio i risultati TRX. Se la post-elaborazione ha esito negativo, l'SDK mantiene gli artefatti originali e il codice di uscita del test.

  • --output <VERBOSITY_LEVEL>

    Specifica il livello di dettaglio dell'output per i risultati del test. I valori validi sono Minimal, Normale Detailed. Il valore predefinito è Normal. Minimal richiede l'anteprima di MTP 2.4.

  • --show-test-results <OUTCOME>

    Seleziona i blocchi di risultati in base al risultato. Nell'anteprima di MTP 2.4 usare passed, failed, skipped, allo none. Il failed valore include anche errori, timeout e annullamenti.

    Combinare passed, failede skipped con virgole, spazi o opzioni ripetute --show-test-results . Non combinare all o none con un altro valore. Questa opzione esplicita sostituisce il --output set di impostazioni indipendentemente dall'ordine delle opzioni.

  • --list-tests [text|json]

    Elenca i test individuati senza eseguirli. Omettere il valore o specificare text per l'output leggibile. A partire da .NET 11 Preview 7, specificare json per un documento JSON con versione che raggruppa i test per assembly, framework di destinazione e architettura e include identificatori, percorsi di origine, metodi, parametri e tratti disponibili.

  • --no-launch-profile

    Non tentare di usare launchSettings.json per configurare l'applicazione. Per impostazione predefinita, launchSettings.json viene usato , che può applicare variabili di ambiente e argomenti della riga di comando al file eseguibile di test.

  • --no-launch-profile-arguments

    Non usare gli argomenti specificati da commandLineArgs nel profilo di avvio per eseguire l'applicazione.

  • --device <DEVICE_ID>

    Seleziona un dispositivo, un emulatore o un simulatore per ogni framework di destinazione in un progetto di test Android o iOS. Il percorso MTP supporta anche progetti di test macOS e Mac Catalyst. Se l'input è interattivo e sono disponibili più dispositivi, dotnet test è possibile chiederne uno.

    Disponibile a partire da .NET 11 Preview 6. Per i progetti con più destinazioni, usare .NET 11 RC 2 o versione successiva in modo che l'individuazione dei dispositivi valuta correttamente ogni framework di destinazione. I progetti di test WebAssembly browser non sono supportati da questa opzione.

  • --list-devices

    Elenca i dispositivi disponibili per un progetto senza eseguire test. Specificare un progetto anziché una soluzione.

    Disponibile a partire da .NET 11 Preview 7.

  • --collect-test-map e --affected-tests

    Raccogliere una mappa di test del repository o eseguire test interessati da una modifica. Queste opzioni sperimentali richiedono un'estensione distribuita separatamente e la variabile di DOTNET_CLI_ENABLE_AFFECTED_TESTS=1 ambiente. Non è possibile combinare le due opzioni. I flussi di lavoro di test interessati non supportano anche i test dei dispositivi, i moduli di test paralleli o i criteri di test minimi.

    Disponibile a partire da .NET 11 RC 1.

  • --property:<NAME>=<VALUE>

    Imposta una o più proprietà MSBuild. Specificare più proprietà ripetendo l'opzione :

    --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

    Il formato -p breve può essere usato per --property. Lo stesso vale per /property:property=value e la sua forma breve è /p. Altre informazioni sugli argomenti disponibili sono disponibili nella documentazione di dotnet msbuild.

  • -?|-h|--help

    Stampa una descrizione di come usare il comando .

  • args

    Specifica argomenti aggiuntivi da passare alle applicazioni di test. Per separare più argomenti usare uno spazio. Per altre informazioni ed esempi su cosa passare, vedere Panoramica di MTP e funzionalità MTP.

    Suggerimento

    Per specificare argomenti aggiuntivi per progetti specifici, usare la proprietà TestingPlatformCommandLineArguments MSBuild. Questa proprietà è particolarmente utile quando la soluzione combina framework di test (ad esempio, MSTest e xUnit.net) o quando solo alcuni progetti fanno riferimento a una particolare estensione. Per altre informazioni, vedere Soluzioni con framework di test misti o estensioni.

Annotazioni

Per abilitare la registrazione della traccia in un file, usare la variabile di ambiente DOTNET_CLI_TEST_TRACEFILE per specificare il percorso del file di traccia.

A partire da .NET 11 RC 1, dotnet test -bl usa una sessione MSBuild per le esecuzioni multiprogetto, multi-destinazione e dispositivo in modo che il log binario contenga la compilazione completa.

Comportamento di output e annullamento

A partire da .NET 11 Preview 6, l'output ANSI interattivo mostra i test attualmente in esecuzione e segnala i conteggi dei test per assembly. La visualizzazione dello stato rimane disabilitata quando l'output viene reindirizzato, l'output ANSI o lo stato di avanzamento è disabilitato o l'ambiente non è interattivo.

A partire da .NET 11 Preview 6, il primo CTRL+C smette di pianificare nuove applicazioni di test e richiede l'annullamento cooperativo. Premere di nuovo CTRL+C per terminare immediatamente i processi figlio. Un'esecuzione interrotta viene chiusa con il codice 3.

L'output dell'host di test live richiede un host MTP che supporta il protocollo 1.1 o versione successiva. Gli host meno recenti mantengono l'output acquisito e lo riproducino per un modulo non riuscito. A partire da .NET 11 Preview 7, i riepiloghi degli errori troncano l'output standard acquisito più lungo di 40 righe alle prime 30 e alle ultime 10 righe. I log di diagnostica mantengono l'output completo.

Per le esecuzioni multimodulo, dotnet test valuta il risultato zero test nell'esecuzione completa a partire da .NET 11 Preview 7. Un modulo senza test non supera l'esecuzione se un altro modulo esegue correttamente i test, a meno che un criterio di test minimo esplicito non richieda più test.

Risultati e artefatti

Quando il layout di output degli artefatti DELL'SDK è abilitato, .NET 11 RC 1 e versioni successive inserisce report MTP, file di copertura e diagnostica per <ArtifactsPath>/test/<project>/<pivot> impostazione predefinita. Un valore esplicito --results-directory o --results-directory-layout ha la precedenza.

A partire da .NET 11 RC 1 e MTP 2.4, le estensioni compatibili possono post-elaborare elementi da un'esecuzione multimodulo. Ad esempio, l'estensione TRX può creare un report unito mantenendo i report per modulo. Per i requisiti di estensione e report, vedere Report di test MTP.

Inoltrare argomenti all'applicazione di test

dotnet test inoltra qualsiasi token che non riconosce all'applicazione di test. Quando viene visualizzata un'opzione riconosciuta tra un nome di opzione non riconosciuto e il relativo valore, la rimozione dell'opzione riconosciuta può modificare il modo in cui i token di sinistra si associano alle opzioni nell'applicazione di test. Per evitare questa ambiguità, inserire gli argomenti dell'applicazione di test dopo un valore letterale --:

dotnet test --results-directory TestResults -- --report-trx --report-trx-filename A.trx

L'esempio precedente richiede il Microsoft.Testing.Extensions.TrxReport pacchetto, come riferimento diretto al pacchetto o tramite una configurazione dell'SDK di test che lo include.

Lo stesso comportamento del parser si applica a dotnet run e dotnet build. Per un esempio dettagliato, vedere Inoltrare gli argomenti all'applicazione nel dotnet run riferimento.

Numero minimo di esecuzioni intere e per modulo

Per --minimum-expected-tests, il -- separatore determina l'ambito dell'opzione:

  • Gli argomenti precedenti-- sono globali. L'agente dotnet test di orchestrazione li interpreta per l'intera esecuzione.
  • Gli argomenti dopo-- sono locali. dotnet test li inoltra a ogni modulo di test, quindi ogni modulo li applica in modo indipendente.

Poiché --minimum-expected-tests è disponibile in entrambi gli ambiti, è possibile richiedere un minimo per l'intera esecuzione, per ogni modulo o per entrambi:

dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

Il comando precedente richiede almeno 5 test nell'intera esecuzione e almeno 2 test in ogni modulo di test.

I due ambiti contano i test ignorati in modo diverso:

Scope I test ignorati vengono conteggiati per il minimo?
Generale Yes. Il dotnet test totale aggregato include test ignorati.
Per modulo No. MTP esclude i test ignorati dal numero di test eseguiti.

A partire dalla .NET 11 SDK, il verdetto zero test per l'intera esecuzione viene deciso una volta dai risultati aggregati. Un modulo che non corrisponde a alcun test, ad esempio a causa di --test-modules o un oggetto globale --filter, viene chiuso con codice 8 (ZeroTests), ma tale codice viene normalizzato per l'esito positivo prima che i risultati vengano aggregati. Di conseguenza, un singolo modulo vuoto non ha esito negativo per l'intera esecuzione, anche se il modulo mantiene la diagnostica Exit code: 8 nell'output per la visibilità.

MTP 4.3.0 e versioni successive forniscono --zero-tests-policy <allow-skipped|strict>. Il valore predefinito, allow-skipped, consente a un modulo tutto ignorato di avere esito positivo. Il strict valore considera i test ignorati come non eseguiti, quindi un modulo tutto ignorato viene chiuso con codice 8. Passare l'opzione dopo -- per inoltrarla a ogni modulo di test:

dotnet test -- --zero-tests-policy strict

Quando non si imposta un valore minimo globale, l'SDK di .NET 11 determina separatamente il verdetto di zero test di esecuzione completa. Un'intera esecuzione ignorata viene chiusa con codice 8 indipendentemente dal valore per modulo --zero-tests-policy .

Quando si specifica --minimum-expected-tests e il valore minimo non viene soddisfatto, l'esecuzione ha esito negativo con codice di uscita 9 (MinimumExpectedTestsPolicyViolation). Questo codice è diverso da 8 in modo che un minimo globale o per modulo più rigoroso non sia confuso con un modulo vuoto. Affinché un valore minimo per modulo restituisca il codice 9 quando il modulo esegue zero test, il modulo di test deve usare MTP 4.4.0 o una versione successiva.

Annotazioni

--minimum-expected-tests 0 non è valido. Per eliminare il codice di uscita zero test, usare --ignore-exit-code 8.

A partire da .NET 11 Preview 6, --tl, --terminalloggere --tlp vengono inoltrati a MSBuild anziché all'applicazione di test. A partire da .NET 12 Preview 1, anche i moduli riconosciuti -mt e -multiThreaded vengono inoltrati a MSBuild. Per passare un'opzione dell'applicazione con uno di questi nomi, inserirla dopo --.

Passare le opzioni in modalità di esecuzione, --help ad esempio e --list-tests direttamente a dotnet test. A partire da .NET 11 Preview 6, l'SDK convalida la modalità di esecuzione negoziata con l'applicazione di test. Se un profilo di avvio o TestingPlatformCommandLineArguments inserisce una di queste opzioni, l'operazione SDK richiesta e l'operazione dell'applicazione non corrispondono e l'esecuzione non riesce con una diagnostica.

Esempi

  • Eseguire i test nella project o nella soluzione nella directory corrente:

    dotnet test

  • Eseguire i test nel TestProject project:

    dotnet test --project ./TestProject/TestProject.csproj

  • Eseguire i test nella soluzione TestProjects:

    dotnet test --solution ./TestProjects/TestProjects.sln

  • Eseguire i test usando l'assembly TestProject.dll:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"

  • Eseguire i test usando TestProject.dll assembly con la directory radice:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"

  • Eseguire tutti i progetti di test a cui fa riferimento un progetto di attraversamento con .NET 11 Preview 7 o versione successiva:

    dotnet test dirs.proj

  • Elencare i test come JSON con .NET 11 Preview 7 o versione successiva:

    dotnet test --list-tests json

  • Eseguire un'app di test MTP basata su file C# con .NET 12 Preview 1 o versione successiva:

    dotnet test App.Tests.cs

  • Eseguire i test nella directory corrente con l'estensione code coverage Microsoft. L'applicazione di test deve fare riferimento Microsoft.Testing.Extensions.CodeCoveragea , direttamente o tramite una configurazione dell'SDK di test che lo include:

    dotnet test --coverage

  • Eseguire i test e archiviare i risultati in una directory specifica:

    dotnet test --results-directory ./TestResults

  • Eseguire i test con output di diagnostica in una directory specifica:

    dotnet test --diagnostic-output-directory ./Diagnostics

  • Eseguire i test assicurando che vengano eseguiti almeno 10 test:

    dotnet test --minimum-expected-tests 10

  • Richiedere almeno 5 test nell'intera esecuzione e almeno 2 test in ogni modulo di test:

    dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

  • Eseguire i test nell'argomento TestProject project, specificando l'argomento -bl (log binario) per msbuild:

    dotnet test --project ./TestProject/TestProject.csproj -bl

  • Eseguire i test nel project, impostando la proprietà /> di MSBuild :

    dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"

Vedere anche

  • Last updated on