共用方式為

Microsoft.Testing.Platform 概觀

  • 發行項

Microsoft.Testing.Platform 是 VSTest 的輕量型且可攜式的替代方案，用於在所有內容中執行測試，包括持續整合 (CI) 管線、CLI、Visual Studio 測試總管和 VS Code 文字總管。 Microsoft.Testing.Platform 會直接內嵌在您的測試專案中，而且沒有其他應用程式相依性，例如執行測試所需的 vstest.console 或 dotnet test。

Microsoft.Testing.Platform 是開放原始碼。 您可以在 Microsoft.Testing.Platform GitHub 存放庫中找到 程式碼。

Microsoft.Testing.Platform 支柱

這個新的測試平臺是以 .NET 開發人員體驗測試小組的經驗為基礎，旨在解決自 2016 年 .NET Core 發行以來遇到的挑戰。 雖然 .NET Framework 與 .NET Core/.NET 之間具有高度的相容性，但外掛程式系統等一些主要功能，以及 .NET 編譯的新可能形式因素，使得開發或完全支援具有目前 VSTest 平台 架構的新運行時間功能相當複雜。

新測試平臺演進的主要驅動因素如下所述：

  • 決定性：確保在不同的內容中執行相同的測試（本機、CI）會產生相同的結果。 新的運行時間不依賴反映或任何其他動態 .NET 運行時間功能來協調測試回合。

  • 運行時間透明度：測試運行時間不會干擾測試架構程式代碼、不會建立 或 AppDomain之類的AssemblyLoadContext隔離內容，也不會使用反映或自定義元件解析程式。

  • 延伸模組的編譯時間註冊：擴充功能，例如測試架構和進程外延伸模組，會在編譯期間註冊，以確保確定性，並協助偵測不一致。

  • 零相依性：平臺的核心是單一 .NET 元件， Microsoft.Testing.Platform.dll其沒有支援的運行時間以外的相依性。

  • 可裝載：測試運行時間可以裝載於任何 .NET 應用程式中。 雖然主控台應用程式通常用來執行測試，但您可以在任何類型的 .NET 應用程式中建立測試應用程式。 這可讓您在特殊內容中執行測試，例如裝置或瀏覽器，可能會有限制。

  • 支援所有 .NET 尺寸：支援目前和未來的 .NET 尺寸，包括原生 AOT。

  • 效能：尋找功能和擴充點之間的正確平衡，以避免使用非基本程式代碼使運行時間膨脹。 新的測試平臺是設計來「協調」測試回合，而不是提供如何執行測試的實作詳細數據。

  • 可延伸：新平臺建置在擴充點上，以允許運行時間執行的最大自定義。 它可讓您設定測試進程主機、觀察測試程式，以及從測試主機進程內的測試架構取用資訊。

  • 單一模組部署：可裝載性功能可啟用單一模組部署模型，其中單一編譯結果可用來支援跨進程和跨進程的所有擴充點，而不需要運送不同的可執行模組。

支援的測試架構

  • MSTest。 在 MSTest 中，對 Microsoft.Testing.Platform 的支援是透過 MSTest 執行器來完成。
  • NUnit. 在 NUnit 中，Microsoft.Testing.Platform 的支援是透過 NUnit 執行器進行。
  • xUnit.net：在 xUnit.net 中，Microsoft.Testing.Platform 的支援是透過 xUnit.net 執行器來完成。
  • TUnit：完全建構在 Microsoft.Testing.Platform 之上，如需詳細資訊，請參閱 TUnit 文件

執行和偵錯測試

Microsoft.Testing.Platform 測試專案會建置為可以直接執行 (或偵錯) 的可執行檔。 沒有額外的測試執行主控台或命令。 如果發生錯誤，應用程式會以非零結束代碼結束，如同大多數可執行檔一般。 如需已知結束代碼的詳細資訊，請參閱 Microsoft.Testing.Platform 結束代碼。

重要

根據預設，Microsoft.Testing.Platform 會收集遙測資料。 如需退出的詳細資訊和選項，請參閱 Microsoft.Testing.Platform 遙測。

使用 dotnet publish 發佈測試專案和直接執行應用程式，是執行測試的另一種方式。 例如，執行 ./Contoso.MyTests.exe。 在某些案例中，您也可以使用 dotnet build 來產生可執行檔，但可能會有邊緣案例需要考慮，例如 原生 AOT。

使用 dotnet run

dotnet run 命令可用來組建及執行您的測試專案。 這是執行測試最簡單的方式，雖然有時最慢。 當您在本機編輯和執行測試時，使用 dotnet run 會很實用，因為它可確保在需要時重建測試專案。 dotnet run 也會自動在目前資料夾中尋找專案。

dotnet run --project Contoso.MyTests

如需 dotnet run 的詳細資訊，請參閱 dotnet 執行。

使用 dotnet exec

dotnet exec 或 dotnet 命令是用來執行 (或運行) 已組建的測試專案，是直接執行應用程式的替代方案。 dotnet exec 需要組建測試專案 dll 的路徑。

dotnet exec Contoso.MyTests.dll

或

dotnet Contoso.MyTests.dll

注意

提供測試專案可執行檔的路徑 (*.exe) 會導致錯誤:

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'

如需 dotnet exec 的詳細資訊，請參閱 dotnet 執行檔。

使用 dotnet test

Microsoft.Testing.Platform 提供具有 vstest.console.exe 和 dotnet test 的相容性圖層，確保您可以在啟用新的執行案例時，可如以往一般執行測試。

dotnet test Contoso.MyTests.dll

選項。

下列清單僅說明平台選項。 若要查看每個延伸模組帶來的特定選項，請參閱延伸模組文件頁面或使用 --help 選項。

  • @

    指定回應檔的名稱。 回應檔名稱必須緊接在 @ 字元後面，中間不可有空格。

    選項在回應檔中解譯時，會被視為出現在命令列的相同位置。 響應檔中的每個自變數都必須在同一行開始和結束。 您無法使用反斜杠字元 （） 串連行。 利用回應檔可以幫助處理可能超出終端機限制的非常長的指令。 您可以將回應檔與內嵌命令行自變數結合。 例如：

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

    其中 filter.rsp 可以有下列內容：

    --filter "A very long filter"

    或者，單一 rsp 檔案可用來指定逾時和篩選，如下所示：

    ./TestExecutable.exe @"arguments.rsp"

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

  • --config-file

    指定 testconfig.json 檔案。

  • --diagnostic

    啟用診斷記錄。 預設的記錄層級是 Trace。 檔案會以下列名稱格式 log_[MMddHHssfff].diag 寫入輸出目錄中。

  • --diagnostic-filelogger-synchronouswrite

    強制內建檔案記錄器同步寫入記錄。 適用於您不想遺失任何記錄項目的案例 (如果流程當機)。 這會讓測試執行變慢。

  • --diagnostic-output-directory

    如果未指定檔案，則診斷記錄的輸出目錄會在預設 TestResults 目錄中產生。

  • --diagnostic-output-fileprefix

    記錄檔名稱的首碼。 預設為 "log_"。

  • --diagnostic-verbosity

    定義使用 --diagnostic 切換時的詳細程度層級。 可用的值為 Trace、Debug、Information、Warning、Error 或 Critical。

  • --exit-on-process-exit

    當依賴進程結束時，結束測試進程。 必須提供 PID。

  • --help

    列印如何使用命令的描述。

  • -ignore-exit-code

    允許忽略某些非零結束代碼，並改為傳回為 0。 如需詳細資訊，請參閱 忽略特定的結束代碼。

  • --info

    顯示 .NET 測試應用程式的進階資訊，例如:

    • 平台。
    • 環境。
    • 每個已註冊的命令行提供者，例如其 name、version、description和 options。
    • 每個已註冊的工具，例如其 command、name、version、description和所有命令行提供者。

    這項功能可用來了解將註冊相同命令行選項的延伸模組，或多個延伸模組版本 (或平台) 之間可用選項的變更。

  • --list-tests

    列出可用的測試。 不會執行測試。

  • --maximum-failed-tests

    指定達到的測試失敗數目上限，當達到時，將會停止測試回合。 支援此切換需要架構作者實作 IGracefulStopTestExecutionCapability 功能。 當測試失敗數量達到該數量時，結束代碼為13。 如需詳細資訊，請參閱 Microsoft.Testing.Platform 結束代碼。

    注意

    此功能可從 1.5 版開始的 Microsoft.Testing.Platform 中使用。

  • --minimum-expected-tests

    指定預期要執行的測試數目下限。 根據預設，至少應該執行一項測試。

  • --results-directory

    要放置測試結果的目錄。 如果指定的目錄不存在，則會建立該目錄。 預設值為 TestResults，位於包含測試應用程式的目錄裡。

  • --timeout

    全域測試執行時間限制。 採用一個自變數做為字串，格式 <value>[h|m|s] 其中 <value> 為 float。

MSBuild 整合

NuGet 套件 Microsoft.Testing.Platform.MSBuild 為 Microsoft.Testing.Platform 提供了與 MSBuild 的各種整合：

  • 支援 dotnet test。 如需更多詳細資訊，請參閱「dotnet test 整合」。
  • 支援 ProjectCapability 需要 Visual Studio 和 Visual Studio Code 測試總管。
  • 自動產生進入點 (Main 方法)。
  • 自動產生組態檔。

注意

此整合會以可轉移的方式運作 (一個參考另一個參考此套件之專案的專案，將會像是直接參考這個套件一樣運作)，而且可以透過 IsTestingPlatformApplication MSBuild 屬性停用。

另請參閱