Condividi tramite

Panoramica di Microsoft.Testing.Platform

  • Articolo

Microsoft.Testing.Platform è un'alternativa leggera e portabile a VSTest per l'esecuzione di test in tutti i contesti, inclusi pipeline di integrazione continua (CI), interfaccia della riga di comando, Esplora test di Visual Studio ed Esplora testo di VS Code. Microsoft.Testing.Platform è incorporato direttamente nei progetti di test e non sono presenti altre dipendenze da app, come ad esempio vstest.console o dotnet test per eseguire i test.

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

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 lo hanno reso complesso per evolvere o supportare completamente la nuova funzionalità di runtime con l'architettura corrente della 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) producano 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 reflection o resolver di assembly personalizzati.

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

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

  • Ospitabile: 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.

  • Prestazioni elevate: trovare il giusto equilibrio tra le funzionalità e i punti di estensione per evitare di gonfiare 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.

  • Estendibile abbastanza: la nuova piattaforma è basata su punti di estendibilità per consentire la massima personalizzazione 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.

  • Distribuzione di un singolo modulo: la funzionalità di hostbilità consente un modello di distribuzione di un singolo modulo, in cui è possibile usare un singolo risultato di compilazione per supportare tutti i punti di estendibilità, sia out-of-process che in-process, senza la necessità di spedire moduli eseguibili diversi.

Framework di test supportati

Eseguire i test e il debug

I progetti di test di Microsoft.Testing.Platform vengono compilati come eseguibili che possono essere eseguiti (o sottoposti a debug) direttamente. Non sono disponibili console o comandi aggiuntivi per l'esecuzione dei test. In caso di errore, l'app viene chiusa con un codice di uscita diverso da zero, come avviene nella maggior parte degli eseguibili. Per altre informazioni sui codici di uscita noti, vedere Codici di uscita di Microsoft.Testing.Platform.

Importante

Per impostazione predefinita, Microsoft.Testing.Platform raccoglie i dati di telemetria. Per altre informazioni e opzioni relative al rifiuto esplicito, vedere Dati di telemetria di Microsoft.Testing.Platform.

Pubblicare il progetto di test usando dotnet publish ed eseguire direttamente l'app è un altro modo per eseguire i test. Ad esempio, l'esecuzione di ./Contoso.MyTests.exe. In alcuni scenari è anche possibile usare dotnet build per produrre l'eseguibile, ma possono esserci casi limite da considerare, come l'AOT nativo.

Utilizzare 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 i test in locale, perché garantisce che il progetto di test venga ricompilato quando necessario. dotnet run troverà automaticamente il progetto nella cartella corrente.

dotnet run --project Contoso.MyTests

Per altre informazioni su dotnet run, vedere dotnet run.

Utilizzare dotnet exec

Il comando dotnet exec o dotnet viene usato per 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

oppure

dotnet Contoso.MyTests.dll

Nota

Specificando il percorso dell'eseguibile del progetto di test (*.exe) si ottiene l'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 altre informazioni su dotnet exec, vedere dotnet exec.

Utilizzare dotnet test

Microsoft.Testing.Platform offre un livello di compatibilità con vstest.console.exe e dotnet test che garantisce l'esecuzione dei test come prima, pur abilitando nuovi scenari di esecuzione.

dotnet test Contoso.MyTests.dll

Opzioni

L'elenco seguente descrive solo le opzioni della piattaforma. Per visualizzare le opzioni specifiche portate 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 backslash (\) 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 i seguenti contenuti:

    --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 integrato a scrivere i log in modo sincrono. Utile per gli scenari in cui non si vuole perdere nessuna voce di registro (se il processo si arresta in modo anomalo). In questo modo viene rallentata l'esecuzione dei test.

  • --diagnostic-output-directory

    La directory di output della registrazione diagnostica. Se non specificato, il file viene generato nella directory predefinita TestResults.

  • --diagnostic-output-fileprefix

    Il prefisso del nome del file di log. Il valore predefinito è "log_".

  • --diagnostic-verbosity

    Definisce il livello di dettaglio quando viene usata l'opzione --diagnostic. I valori disponibili sono Trace, Debug, Information, Warning, Erroro Critical.

  • --exit-on-process-exit

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

  • --help

    Stampa le istruzioni di utilizzo del comando.

  • -ignore-exit-code

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

  • --info

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

    • La piattaforma.
    • L’ambiente.
    • Ogni provider della riga di comando registrato, ad esempio name, version, descriptione options.
    • Ogni strumento registrato, come il command, il name, il version, il 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 alle opzioni disponibili tra più versioni di un'estensione (o della 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 l'abilità IGracefulStopTestExecutionCapability. Il codice di uscita quando si raggiunge quel numero di errori nei test è 13. Per altre informazioni, vedere i 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 di esecuzione di test globale. Accetta un argomento come stringa nel formato <value>[h|m|s] in cui <value> è float.

Integrazione di MSBuild

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

  • Supporto di dotnet test. Per altre informazioni, vedere Integrazione di test dotnet.
  • Supporto per ProjectCapability richiesto da Visual Studio e Visual Studio Code Esplora test.
  • Generazione automatica del punto di ingresso (metodo Main).
  • 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 facesse riferimento al pacchetto) e può essere disabilitato tramite la proprietà MSBuild IsTestingPlatformApplication.

Vedi anche