Përshëndetje të gjithëve. Sot po ndajmë me ju pjesën përfundimtare të artikullit , përkthimi i të cilit është përgatitur veçanërisht për studentët e kursit .
Testimi i implementimit
Stili i testimit të shqyrtuar është një qasje e fuqishme, e cila na lejon të kryejmë testimin e kutisë së bardhë për të verifikuar funksionimin e brendshëm të kodit tonë të infrastrukturës. Megjithatë, ai disi kufizon atë që mund të verifikojmë. Testet kryhen mbi një plan implementimi in-memory, i krijuar nga Pulumi para implementimit të drejtpërdrejtë dhe prandaj implementimi vetë nuk mund të testohet. Për këto raste, Pulumi ka një kuadër testimi integrues. Dhe këto dy qasje funksionojnë shkëlqyeshëm së bashku!
Kuadri i testimit integrues të Pulumi është shkruar në Go, dhe pikërisht me ndihmën e tij ne testojmë shumicën e kodit tonë të brendshëm. Nëse qasja e shqyrtuar më parë e testimit modular ishte më shumë si testimi i kutisë së bardhë, atëherë testimi integrues është kutia e zezë. (Ka gjithashtu variante të testimit të brendshëm të hollësishëm.) Ky kuadër është krijuar për të marrë një program të plotë Pulumi dhe për të kryer për të operacione të ndryshme të jetës së ciklit, siç janë implementimi i një stekje të re nga fillimi, azhurnimi i saj me variacione dhe fshirja, ndoshta disa herë. Ne i ekzekutojmë ato rregullisht (p.sh., natën) dhe si teste stresi.
(Ne , që mundësi të ngjashme për testimin integrues të jenë në SDK-në natyrore të gjuhëve. Ju mund të përdorni kuadrin e testimit integrues Go pavarësisht nga gjuha në të cilën është shkruar programi juaj i Pulumi).
Duke e ekzekutuar programin me ndihmën e këtij kuadri ju mund të verifikoni:
- Kodi i projektit tuaj është sintaksikisht i saktë dhe funksionon pa gabime.
- Caktimet e konfigurimit të stekës dhe sekretet funksionojnë dhe interpretohen saktë.
- Projekti juaj mund të implementohet me sukses në ofruesin e tuaj të preferuar të cloud.
- Projekti juaj mund të azhurnohet me sukses nga gjendja fillestare në N gjendje të tjera.
- Projekti juaj mund të shkatërrohet dhe fshihet me sukses nga ofruesi juaj i cloud.
Siç do të shohim së shpejti, ky kuadër gjithashtu mund të përdoret për të kryer validimin e runtime.
Test i thjeshtë i integrimit
Për ta parë këtë në veprim, ne do të shohim në repositorin pulumi/examples, pasi ekipi ynë dhe komuniteti Pulumi e përdorin atë për të testuar kërkesat e veta të bazës, komitet dhe ndërtimet e natës.
Më poshtë është një test i thjeshtuar i :
example_test.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,
},
})
} Ky test kalon përmes ciklit të jetës së krijimit, modifikimit dhe shkatërrimit të një staku për dosjen aws-js-s3-folder. Do të marrë rreth një minutë për të raportuar testin e kaluar:
$ go test .
PASS
ok ... 43.993s Ka shumë parametra për të konfiguruar sjelljen e këtyre testeve. Lista e plotë e opsioneve mund të shikohet ProgramTestOptions. Për shembull, mund të konfiguroni endpoint-in Jaeger për gjurmimin (Tracing), të specifikoni se prisni dështimin e testit në testimin negativ (ExpectFailure), të aplikoni një seri "korrigjimesh" në program për kalimin e gjendjeve (EditDirs) dhe shumë më tepër. Le të shohim si t'i përdorim ato për të verifikuar shpërndarjen e aplikacioneve.
Verifikimi i pronave të burimeve
Integrimi qĂ« u pĂ«rmend mĂ« lart siguron qĂ« programi ynĂ« "punon" â nuk dĂ«shton. Por çfarĂ« nĂ«se duam tĂ« verifikojmĂ« pronat e stack-ut tĂ« marrĂ«? PĂ«r shembull, se disa lloje burimesh ishin (ose nuk ishin) krijuar dhe se ato kanĂ« disa atributet tĂ« caktuara.
Parametri ExtraRuntimeValidation për ProgramTestOptions na lejon të shohim në statusin e regjistruar nga Pulumi pas shpërndarjes (post-deployment state), në mënyrë që të mund të bëjmë verifikime të tjera. Kjo përfshin një pamje të plotë të gjendjes së stack-ut rezultues, duke përfshirë konfigurimin, vlerat e dalura të eksportuara, të gjitha burimet dhe vlerat e pronave të tyre, si dhe të gjitha varësitë midis burimeve.
Për të parë një shembull të thjeshtë të kësaj, le të kontrollojmë se programi ynë krijon një S3 Bucket:
integration.ProgramTest(t, &integration.ProgramTestOptions{
\/\/ si më parë...
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, "Pr expecting to find a single AWS S3 Bucket")
},
})Tani, kur ne do ta ekzekutojmë go test, ai do të kalojë jo vetëm përmes një serie testesh të ciklit të jetës, por gjithashtu, pas një implementimi të suksesshëm të stek-ut, do të kryejë një kontrolle shtesë të gjendjes përfundimtare.
Testet në kohë reale
deri tani tĂ« gjitha testet kanĂ« qenĂ« ekskluzivisht pĂ«r sjelljen gjatĂ« implementimit dhe pĂ«r modelin e burimeve Pulumi. ĂfarĂ« tĂ« bĂ«jmĂ«, nĂ«se dĂ«shiron tĂ« verifikosh qĂ« infrastruktura jote e pĂ«rgatitur funksionon vĂ«rtet? PĂ«r shembull, a funksionon makina virtuale, a pĂ«rmban S3 bucket ajo qĂ« presim, dhe kĂ«shtu me radhĂ«.
Ju ndoshta tashmë e keni kuptuar se si ta bëni këtë: opsioni ExtraRuntimeValidation për ProgramTestOptions është një mundësi e shkëlqyer për këtë. Në këtë fazë, ju ekzekutoni një test të rastësishëm Go me qasje në gjendjen e plotë të burimeve të programit tuaj. Kjo gjendje përfshin informata të tilla si adresat IP të makinave virtuale, URL-të dhe gjithçka që nevojitet për ndërveprim real me aplikacionet dhe infrastrukturën e shpërndara në cloud.
Për shembull, programi ynë testues eksporton pronën webEndpoint të bucket-it të quajtur websiteUrl, e cila është një URL e plotë ku mund të marrim dokumentin e index. Megjithëse ne mund të shqyrtojmë skedarin e gjendjes për të gjetur bucket dhe ta lexojmë këtë pronë drejtpërdrejt, në shumë raste stekët tanë eksportojnë prona të dobishme si kjo, që neve na është e lehtë t'i përdorim për verifikim:
integration.ProgramTest(t, &integration.ProgramTestOptions{
\/\/ si më parë ...
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!")
},
}) Ashtu si verifikimet tona tĂ« mĂ«parshme nĂ« kohĂ« reale, ky kontroll do tĂ« ekzekutohet menjĂ«herĂ« pas ngritjes sĂ« stek-ut, dhe e gjithĂ« kjo nĂ« pĂ«rgjigje tĂ« njĂ« thirrje tĂ« thjeshtĂ« go test. Dhe kjo Ă«shtĂ« vetĂ«m maja e ajsbergut â tĂ« gjitha mundĂ«sitĂ« testuese tĂ« Go janĂ« tĂ« gjitha tĂ« disponueshme, qĂ« ju mund tĂ« shkruani nĂ« kod.
Integrimi i vazhdueshëm i infrastrukturës
ĂshtĂ« mirĂ« qĂ« tĂ« keni mundĂ«sinĂ« tĂ« ekzekutoni teste nĂ« laptopin tuaj, kur ka shumĂ« ndryshime nĂ« infrastrukturĂ«, pĂ«r t'i kontrolluar ato para se t'i dĂ«rgoni pĂ«r shqyrtim tĂ« kodit. Por ne dhe shumĂ« nga klientĂ«t tanĂ« i testojmĂ« infrastrukturat nĂ« faza tĂ« ndryshme tĂ« ciklit tĂ« zhvillimit:
- Në çdo kërkesë të hapur të pullës për testin përpara bashkimit.
- Në përgjigje të çdo komiti, për të verifikuar që bashkimi është kryer siç duhet.
- Rregullisht, për shembull, natën ose çdo javë për teste shtesë.
- Si pjesë e testimit të performancës ose testimit të stresit, që zakonisht kryhen për një periudhë të gjatë kohe dhe ekzekutojnë teste paralelisht dhe/ose zhvillojnë të njëjtin program disa herë.
Për çdo një prej tyre, Pulumi mbështet integrimin me sistemin tuaj të preferuar të integrazhës së vazhdueshme. Me integrimin e vazhdueshëm, kjo ju ofron të njëjtin mbulim testesh për infrastrukturën tuaj, ashtu si për software-in aplikativ.
Pulumi ka mbështetje për sistemet CI më të zakonshme. Ja disa prej tyre:
Për më shumë informacion, ju lutemi referojuni dokumentacionit për .
Mjediset efemere
Një mundësi shumë e fuqishme që hapet është mundësia për të zhvilluar mjedise efemere vetëm për qëllime testimi të pranuara. Koncepti Pulumi është projektuar në mënyrë që të lehtësojë zhvillimin dhe shkatërrimin e mjediseve krejtësisht të izoluara dhe të pavarura, gjithçka në disa direktiva të thjeshta CLI ose me ndihmën e kornizës së testimit të integrimit.
Nëse përdorni GitHub, atëherë Pulumi ofron , e cila do t'ju ndihmojë të lidhni testimin e pranuar me kërkesat e pullës brenda CI-të tuaj. Thjesht instaloni aplikacionin në repositorin GitHub, dhe Pulumi në CI-në tuaj dhe informacioni mbi paraprakët e infrastrukturës, azhurnimet dhe rezultatet e testeve do të shtohet në kërkesat e pullës:
Duke përdorni Pulumi për testet tuaja kryesore të pranimit, do të keni mundësi të reja automatizimi që do të përmirësojnë performancën e ekipit dhe do t'ju japin siguri për cilësinë e ndryshimeve.
PĂ«rfundimi
Në këtë artikull, pamë se duke përdorur gjuhët e programimit të përgjithshme, na hapet shumë metoda zhvillimi softueri që ishin të dobishme për zhvillimin e aplikacioneve tona. Këto përfshijnë testimin modular, testimin e integrimit, si dhe ndërveprimin e tyre për të kryer testime të gjera runtime. Testet janë të lehta për t'u ekzekutuar me kërkesë ose në sistemin tuaj CI.
Pulumi â njĂ« program i hapur, i cili Ă«shtĂ« falas pĂ«r t'u pĂ«rdorur dhe punon me gjuhĂ«t dhe cloud-et tuaja tĂ« preferuara â !
â
Burimi: habr.com
