我有一個用 C# 撰寫的測驗框架，我正在使用 Selenium、nUnit 和 Specflow。
Visual Studio 是工具，我有正常的專案檔案夾結構（頁面、掛鉤、步驟、功能）。
測驗用例與 AzureDevOps 相關聯，代碼被推送到 repo 并且 pipilines 運行良好。
我的問題是我想將代碼隱藏在功能級別下。
這個想法是其他人可以創建新的功能檔案并在其中創建測驗，但我不希望他們能夠看到那些 Gherkin 陳述句下的代碼。
所以他們應該只能創建和撰寫新功能，但看不到下面的代碼。
您能否給我一些想法如何實作這一目標？
uj5u.com熱心網友回復：
您可以從外部程式集匯入系結。在 SpecFlow.json 中，添加：
{
"stepAssemblies": [
{
"assembly": "Name.Of.Your.StepDefinitions.dll"
}
]
}
雖然這通常用作在多個專案中重用步驟定義的一種方式，但您可以使用它來“隱藏”測驗撰寫者的步驟定義。步驟定義將是一個預編譯的 DLL 檔案，它們可以匯入到不同的 Visual Studio 解決方案中。
這需要 Visual Studio 中的兩種不同解決方案：
包含步驟定義類的常規類別庫。您可能需要選擇 .NET Core 或 .NET Framework 5 ，因為它必須與單元測驗框架集成。我不相信 .NET Standard 會起作用（但您當然可以嘗試）。
測驗人員可以使用的另一個 Visual Studio 解決方案，其中包含功能檔案。該專案將參考您將從專案#1 創建的 DLL 檔案。
挑戰在于傳播這個 DLL 檔案。您所做的任何更新都需要提供給測驗人員的 Visual Studio 解決方案。我想到了幾個選項：
手動更新解決方案 #2。
為解決方案 #1 創建一個 NuGet 包。在 Azure DevOps 中設定構建管道，以在您進行代碼更改時構建、打包并將此 NuGet 包推送到專案的“工件”源。某人（您或測驗人員）需要在解決方案 #2 中更新該 NuGet 包。
作為替代方案，讓每個人都可以訪問功能和步驟定義，但在需要您作為審閱者的存盤庫上強制執行拉取請求策略。這樣你就可以保護主分支作為看門人。測驗人員可以提交對步驟定義的更改，如果更改不令人滿意，您可以自由拒絕他們的拉取請求。
當然，這取決于團隊結構。如果您有外部承包商，則可能不希望共享步驟定義代碼。只是不要僅僅因為你不信任他們的技能水平而限制他們的能力。如果他們更改步驟定義檔案，請使用要求您作為審閱者的拉取請求策略。這使您可以從別人的勞動中受益，同時仍然讓您控制。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/505098.html