Condividi tramite

Panoramica di Microsoft.Testing.Platform

Microsoft.Testing.Platform è un'alternativa leggera e portabile a vsTest per l'esecuzione di test in tutti i contesti, incluse pipeline di integrazione continua, interfaccia della riga di comando, Esplora test di Visual Studio e Esplora test di VS Code. Microsoft.Testing.Platform è incorporato direttamente nei progetti di test e non sono presenti altre dipendenze dell'app, ad esempio vstest.console o dotnet test necessarie per eseguire i test.

Microsoft.Testing.Platform è open source. È possibile trovare il codice Microsoft.Testing.Platform nel repository GitHub Microsoft/testfx.

Pilastri di Microsoft.Testing.Platform

Questa nuova piattaforma di test si basa sull'esperienza del team di test di .NET Developer Experience Testing e mira a risolvere le sfide riscontrate dal rilascio di .NET Core nel 2016. Anche se esiste un elevato livello di compatibilità tra .NET Framework e .NET Core/.NET, alcune funzionalità chiave come il sistema plug-in e i nuovi possibili fattori di forma delle compilazioni .NET hanno reso complessa l'evoluzione o il supporto completo della nuova funzionalità di runtime con l'architettura corrente piattaforma VSTest.

I principali fattori di guida per l'evoluzione della nuova piattaforma di test sono descritti in dettaglio nel modo seguente:

  • determinismo: garantire che l'esecuzione degli stessi test in contesti diversi (locale, CI) produca lo stesso risultato. Il nuovo runtime non si basa sulla reflection o su altre funzionalità di runtime .NET dinamiche per coordinare un'esecuzione di test.

  • trasparenza del runtime: il runtime di test non interferisce con il codice del framework di test, non crea contesti isolati come AppDomain o AssemblyLoadContexte non usa i resolver di reflection o di assembly personalizzati.

  • la registrazione in fase di compilazione delle estensioni: le estensioni, ad esempio framework di test e estensioni in/out-of-process, vengono registrate durante la fase di compilazione per garantire determinismo e per facilitare il rilevamento delle incoerenze.

  • Dipendenze zero: il nucleo della piattaforma è un singolo assembly .NET, Microsoft.Testing.Platform.dll, che non ha dipendenze diverse dai runtime supportati.

  • Hostable: il runtime di test può essere ospitato in qualsiasi applicazione .NET. Mentre un'applicazione console viene comunemente usata per eseguire i test, è possibile creare un'applicazione di test in qualsiasi tipo di applicazione .NET. In questo modo è possibile eseguire test all'interno di contesti speciali, ad esempio dispositivi o browser, in cui potrebbero esserci limitazioni.

  • Supportare tutti i fattori di forma .NET: supportare fattori di forma .NET correnti e futuri, tra cui AOT nativo.

  • performante: trovare il giusto equilibrio tra le funzionalità e i punti di estensione per evitare di appesantire il runtime con codice non fondamentale. La nuova piattaforma di test è progettata per "orchestrare" un'esecuzione di test, invece di fornire dettagli sull'implementazione su come eseguire questa operazione.

  • Extensible enough: la nuova piattaforma è basata su punti di estendibilità per consentire la personalizzazione massima dell'esecuzione del runtime. Consente di configurare l'host del processo di test, osservare il processo di test e utilizzare le informazioni del framework di test all'interno del processo host di test.

  • singolo modulo di distribuzione: la funzionalità di hostability consente un modello di distribuzione di un singolo modulo, in cui è possibile usare un singolo output di compilazione per supportare tutti i punti di estendibilità, sia esterni che interni, senza la necessità di distribuire moduli eseguibili diversi.

Sistemi di test supportati

  • MSTest. In MSTest il supporto di Microsoft.Testing.Platform viene eseguito tramite strumento di esecuzione MSTest.
  • NUnit. In NUnit, il supporto di Microsoft.Testing.Platform è fornito dal runner NUnit .
  • xUnit.net: In xUnit.net, il supporto per Microsoft.Testing.Platform è fornito tramite il runner di xUnit.net .
  • TUnit: interamente costruito sopra Microsoft.Testing.Platform, per ulteriori informazioni, si prega di consultare la documentazione di TUnit .

Avviare e fare il debug dei test

Microsoft.Testing.Platform i progetti di test vengono compilati come eseguibili che possono essere eseguiti o sottoposti a debug direttamente. Non ci sono ulteriori test che riguardano la console o i comandi. L'app viene chiusa con un codice di uscita diverso da zero se si verifica un errore, che è tipico per la maggior parte dei file eseguibili. Per altre informazioni sui codici di uscita noti, vedere codici di uscita Microsoft.Testing.Platform.

Consiglio

È possibile ignorare un codice di uscita specifico usando l'opzione della riga di comando --ignore-exit-code.

È anche possibile impostare le opzioni della riga di comando applicabili a un progetto di test specifico nel file di progetto usando la proprietà TestingPlatformCommandLineArguments MSBuild. Un caso d'uso comune riguarda i progetti di test con tutti i test ignorati, che in genere verranno chiusi con codice di uscita 8 (la sessione di test ha eseguito zero test). In questo scenario, è possibile aggiungere quanto segue in un PropertyGroup nel file di progetto:

<TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>

Importante

Per impostazione predefinita, Microsoft.Testing.Platform raccoglie i dati di telemetria. Per ulteriori informazioni e opzioni sulla rinuncia, vedere la telemetria di Microsoft.Testing.Platform.

La pubblicazione del progetto di test usando dotnet publish ed esecuzione diretta dell'app è un altro modo per eseguire i test. Ad esempio, l'esecuzione del ./Contoso.MyTests.exe. In alcuni scenari è anche possibile usare dotnet build per produrre l'eseguibile, ma esistono casi limite da considerare, ad esempio Nativo AOT.

Usare dotnet run

Il comando dotnet run può essere usato per compilare ed eseguire il progetto di test. Questo è il modo più semplice, anche se a volte più lento, per eseguire i test. L'uso di dotnet run è pratico quando si modificano ed eseguono test in locale, perché garantisce che il progetto di test venga ricompilato quando necessario. dotnet run troverà automaticamente anche il progetto nella cartella corrente.

dotnet run --project Contoso.MyTests

Per ulteriori informazioni su dotnet run, consultare dotnet run.

Usare dotnet exec

Il comando dotnet exec o dotnet viene usato per eseguire (o eseguire) un progetto di test già compilato, questa è un'alternativa all'esecuzione diretta dell'applicazione. dotnet exec richiede il percorso della DLL del progetto di test compilato.

dotnet exec Contoso.MyTests.dll

o

dotnet Contoso.MyTests.dll

Nota

Se si specifica il percorso dell'eseguibile del progetto di test (*.exe) viene generato un errore:

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

Per ulteriori informazioni su dotnet exec, consultare dotnet exec.

Usare dotnet test

Microsoft.Testing.Platform offre un livello di compatibilità con vstest.console.exe e dotnet test assicurandosi di poter eseguire i test come prima durante l'abilitazione di un nuovo scenario di esecuzione.

dotnet test Contoso.MyTests.dll

Opzioni

L'elenco seguente descrive solo le opzioni della piattaforma. Per visualizzare le opzioni specifiche riportate da ogni estensione, fare riferimento alla pagina della documentazione dell'estensione o usare l'opzione --help.

  • @

    Specifica il nome del file di risposta. Il nome del file di risposta deve seguire immediatamente il carattere @ senza spazi vuoti tra il carattere @ e il nome del file di risposta.

    Le opzioni in un file di risposta vengono interpretate come se fossero presenti in tale posizione nella riga di comando. Ogni argomento in un file di risposta deve iniziare e terminare sulla stessa riga. Non è possibile utilizzare il carattere barra rovesciata () per concatenare le righe. L'uso di un file di risposta consente di eseguire comandi molto lunghi che potrebbero superare i limiti del terminale. È possibile combinare un file di risposta con argomenti della riga di comando inline. Per esempio:

    ./TestExecutable.exe @"filter.rsp" --timeout 10s

    dove filter.rsp può avere il contenuto seguente:

    --filter "A very long filter"

    In alternativa, è possibile usare un singolo file rsp per specificare sia il timeout che il filtro come indicato di seguito:

    ./TestExecutable.exe @"arguments.rsp"

    --filter "A very long filter"
--timeout 10s

  • --config-file

    Specifica un file testconfig.json.

  • --diagnostic

    Abilita la registrazione diagnostica. Il livello di log predefinito è Trace. Il file viene scritto nella directory di output con il formato del nome seguente, log_[MMddHHssfff].diag.

  • --diagnostic-filelogger-synchronouswrite

    Forza il logger di file predefinito a scrivere i log in modo sincrono. Utile per le situazioni in cui non si vogliono perdere registrazioni di log (se il processo si arresta in modo anomalo). Ciò rallenta l'esecuzione del test.

  • --diagnostic-output-directory

    La directory di output per la registrazione diagnostica, se non specificata, è generata nella directory predefinita TestResults.

  • --diagnostic-output-fileprefix

    Prefisso per il nome del file di log. Il valore predefinito è "log_".

  • --diagnostic-verbosity

    Definisce il livello di verbosità quando viene utilizzato l'interruttore --diagnostic. I valori disponibili sono Trace, Debug, Information, Warning, Erroro Critical.

  • --exit-on-process-exit

    Uscire dal processo di test se il processo dipendente esce. È necessario specificare il PID.

  • --help

    Stampa una descrizione di come usare il comando .

  • --ignore-exit-code

    Consente di ignorare alcuni codici di uscita diversi da zero e restituiti come 0. Per altre informazioni, vedere Ignorare i codici di uscita specifici.

  • --info

    Visualizza informazioni avanzate sull'applicazione di test .NET, ad esempio:

    • La piattaforma.
    • Ambiente.
    • Ogni provider registrato della riga di comando, come name, version, descriptione options.
    • Ogni strumento registrato, come il relativo command, name, version, descriptione tutti i provider della riga di comando.

    Questa funzionalità viene usata per comprendere le estensioni che registrano la stessa opzione della riga di comando o le modifiche nelle opzioni disponibili tra più versioni di un'estensione (o la piattaforma).

  • --list-tests

    Elencare i test disponibili. I test non verranno eseguiti.

  • --maximum-failed-tests

    Specifica il numero massimo di errori di test che, quando raggiunto, arresterà l'esecuzione del test. Il supporto per questa opzione richiede agli autori del framework di implementare la funzionalità di IGracefulStopTestExecutionCapability. Il codice di uscita quando raggiunge tale quantità di errori di test è 13. Per altre informazioni, vedere codici di uscita di Microsoft.Testing.Platform.

    Nota

    Questa funzionalità è disponibile in Microsoft.Testing.Platform a partire dalla versione 1.5.

  • --minimum-expected-tests

    Specifica il numero minimo di test che devono essere eseguiti. Per impostazione predefinita, è previsto che venga eseguito almeno un test.

  • --results-directory

    Directory in cui verranno inseriti i risultati del test. Se la directory specificata non esiste, viene creata. Il valore predefinito è TestResults nella directory che contiene l'applicazione di test.

  • --timeout

    Timeout globale di esecuzione del test. Accetta un argomento come stringa nel formato <value>[h|m|s] in cui <value> è di tipo float.

Integrazione di MSBuild

Il pacchetto NuGet Microsoft.Testing.Platform.MSBuild offre varie integrazioni per Microsoft.Testing.Platform con MSBuild:

  • Supporto per dotnet test. Per altre informazioni, vedere Test con dotnet test.
  • Supporto per ProjectCapability richiesto dagli Esploratori Test Visual Studio e Visual Studio Code.
  • Generazione automatica del punto di ingresso ( metodoMain).
  • Generazione automatica del file di configurazione.

Nota

Questa integrazione funziona in modo transitivo (un progetto che fa riferimento a un altro progetto che fa riferimento a questo pacchetto si comporta come se fa riferimento al pacchetto) e può essere disabilitato tramite la proprietà IsTestingPlatformApplication MSBuild.

Vedere anche

  • Last updated on