大家好。 今天我們要跟大家分享的是文章的最後一部分。 ，其翻譯是專門為課程學生準備的 .
部署測試
這種測試風格是一種強大的方法，允許我們執行白盒測試來測試基礎設施程式碼的內部工作原理。 然而，它在一定程度上限制了我們可以測試的內容。 測試是根據 Pulumi 在實際部署之前創建的記憶體部署計劃進行的，因此無法測試部署本身。 對於這種情況，Pulumi 有一個整合測試框架。 這兩種方法配合得很好！
Pulumi 整合測試框架是用 Go 編寫的，這是我們測試大部分內部程式碼的方式。 雖然前面討論的單元測試方法更像是白盒測試，但整合測試是黑盒。 （還有嚴格內部測試的選項。）創建該框架是為了獲取完整的 Pulumi 程序並對其執行各種生命週期操作，例如從頭開始部署新堆疊、使用變體更新它以及刪除它，可能會多次。 我們定期（例如在晚上）運行它們並作為壓力測試。
（我們 ，以便在語言的原生 SDK 中提供類似的整合測試功能。 無論您的 Pulumi 程式使用何種語言編寫，您都可以使用 Go 整合測試框架。
透過使用此框架運行程序，您可以檢查以下內容：
- 您的專案程式碼語法正確且執行沒有錯誤。
- 堆疊和機密配置設定有效並被正確解釋。
- 您的專案可以成功部署在您選擇的雲端提供者。
- 你的專案可以成功從初始狀態升級到其他N個狀態。
- 您的專案可以成功銷毀並從您的雲端提供者中刪除。
正如我們稍後將看到的，該框架還可用於執行運行時驗證。
簡單的整合測試
要查看其實際效果，我們將查看儲存庫 pulumi/examples，因為我們的團隊和 Pulumi 社區使用它來測試我們自己的拉取請求、提交和夜間構建。
下面是我們的簡化測試 :
範例_測試.go：
package test
import (
"os"
"path"
"testing"
"github.com/pulumi/pulumi/pkg/testing/integration"
)
func TestExamples(t *testing.T) {
awsRegion := os.Getenv("AWS_REGION")
if awsRegion == "" {
awsRegion = "us-west-1"
}
cwd, _ := os.Getwd()
integration.ProgramTest(t, &integration.ProgramTestOptions{
Quick: true,
SkipRefresh: true,
Dir: path.Join(cwd, "..", "..", "aws-js-s3-folder"),
Config: map[string]string{
"aws:region": awsRegion,
},
})
}
此測試經歷了創建、修改和銷毀資料夾堆疊的基本生命週期 aws-js-s3-folder。 報告通過的測試大約需要一分鐘：
$ go test .
PASS
ok ... 43.993s
有許多選項可以自訂這些測試的行為。 查看完整的選項清單。 ProgramTestOptions。 例如，您可以設定 Jaeger 端點來追蹤（Tracing），表示如果測試結果為負（ExpectFailure），對程式應用一系列「編輯」以實現狀態的連續轉換（EditDirs） 以及更多。 讓我們看看如何使用它們來測試您的應用程式部署。
檢查資源屬性
上面討論的整合確保了我們的程式「正常運作」——不會崩潰。 但是如果我們想檢查生成的堆疊的屬性怎麼辦？ 例如，某些類型的資源已經（或尚未）被供應並且它們具有某些屬性。
參數 ExtraRuntimeValidation 為 ProgramTestOptions 允許我們查看 Pulumi 記錄的部署後狀態，以便我們可以進行其他檢查。 這包括產生的堆疊狀態的完整快照，包括配置、匯出的輸出值、所有資源及其屬性值以及資源之間的所有依賴關係。
要查看一個基本範例，讓我們檢查一下我們的程式是否創建了一個 S3 桶:
integration.ProgramTest(t, &integration.ProgramTestOptions{
// as before...
ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
var foundBuckets int
for _, res := range stack.Deployment.Resources {
if res.Type == "aws:s3/bucket:Bucket" {
foundBuckets++
}
}
assert.Equal(t, 1, foundBuckets, "Expected to find a single AWS S3 Bucket")
},
})現在，當我們執行 go test 時，它不僅會經歷一系列生命週期測試，而且在成功部署堆疊後，它還會對結果狀態執行額外的檢查。
運行時測試
到目前為止，所有測試都純粹是關於部署行為和 Pulumi 資源模型。 如果您想驗證您配置的基礎架構是否確實有效該怎麼辦？ 例如，虛擬機器正在運行，S3儲存桶包含我們期望的內容等等。
您可能已經猜到如何執行此操作：選項 ExtraRuntimeValidation 為 ProgramTestOptions ——這是一個很好的機會。 此時，您可以執行自訂 Go 測試，並可以存取程式資源的完整狀態。 此狀態包括虛擬機器 IP 位址、URL 以及與產生的雲端應用程式和基礎架構實際互動所需的所有資訊等資訊。
例如，我們的測試程序導出屬性 webEndpoint 稱為桶 websiteUrl，這是我們可以獲得配置的完整 URL index document。 雖然我們可以深入研究狀態文件來找到 bucket 並直接讀取該屬性，但在許多情況下，我們的堆疊會導出這樣有用的屬性，我們發現這些屬性可以方便地用於檢查：
integration.ProgramTest(t, &integration.ProgramTestOptions{
// as before ...
ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
url := "http://" + stack.Outputs["websiteUrl"].(string)
resp, err := http.Get(url)
if !assert.NoError(t, err) {
return
}
if !assert.Equal(t, 200, resp.StatusCode) {
return
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
if !assert.NoError(t, err) {
return
}
assert.Contains(t, string(body), "Hello, Pulumi!")
},
})
與我們之前的運行時檢查一樣，此檢查將在引發堆疊後立即執行，所有這些都是為了響應簡單的調用 go test。 這只是冰山一角——您可以用程式碼編寫的每個 Go 測試功能都可用。
持續的基礎設施集成
當進行大量基礎設施變更以在提交程式碼審查之前進行測試時，能夠在筆記型電腦上執行測試是件好事。 但我們和我們的許多客戶在開發生命週期的各個階段測試基礎設施：
- 在合併之前的每個開放拉取請求中進行測試。
- 為了回應每次提交，請仔細檢查合併是否正確完成。
- 定期（例如晚上或每週）進行額外測試。
- 作為效能或壓力測試的一部分，通常會運行很長一段時間並並行運行測試和/或多次部署相同程式。
對於其中的每一個，Pulumi 都支援與您最喜歡的持續整合系統整合。 透過持續集成，這可以為您的基礎架構提供與應用程式軟體相同的測試覆蓋範圍。
Pulumi 支援常見的 CI 系統。 這裡是其中的一些：
有關更詳細的信息，請參閱文檔 .
短暫的環境
一個非常強大的機會是能夠僅出於驗收測試目的部署臨時環境。 概念 Pulumi 旨在輕鬆部署和拆除完全隔離和獨立的環境，所有這些都可以透過幾個簡單的 CLI 命令或使用整合測試框架來實現。
如果您使用 GitHub，那麼 Pulumi 提供 ，這將幫助您將驗收測試連接到 CI 管道中的拉取請求。 只需在 GitHub 儲存庫中安裝該應用程序，Pulumi 就會向您的 CI 和池請求添加有關基礎設施預覽、更新和測試結果的資訊：
當您使用 Pulumi 進行核心驗收測試時，您將獲得新的自動化功能，這將提高團隊生產力並使您對變更的品質充滿信心。
總
在本文中，我們看到，透過使用通用程式語言，我們可以使用許多在開發應用程式時有用的軟體開發技術。 它們包括單元測試、整合測試以及它們如何協同工作來執行廣泛的運行時測試。 測試很容易按需運行或在 CI 系統中運行。
普魯米 - 開源軟體，免費使用並與您最喜歡的程式語言和雲端一起使用 - !
→
來源： www.habr.com