Përshëndetje të gjithëve. Sot po ndajmë me ju pjesën përfundimtare të artikullit , përkthyer veçanërisht për studentët e kursit .
Testimi i vendosjes
Stili i testimit të shqyrtuar është një qasje e fuqishme që na lejon të realizojmë testimin e kutisë së bardhë për të verifikuar brendësitë e funksionimit të kodit tonë të infrastrukturës. Megjithatë, kjo qasje është disi e kufizuar në atë që mund të kontrollojmë. Testet ekzekutohen në bazë të një plani të memorie in-memory të vendosjes, i krijuar nga Pulumi para vendosjes së drejtpërdrejtë dhe prandaj vetë vendosja nuk mund të testohet. Për këto raste, Pulumi ofron një kornizë për testin e integrimeve. Dhe këto dy qasje punojnë shumë mirë së bashku!
Korniza e testimit të integrimeve Pulumi është shkruar në Go, dhe me ndihmën e saj ne testojmë shumicën e kodit tonë të brendshëm. Nëse qasja e testimit modular të shqyrtuar më parë ishte më shumë e ngjashme me testimin e kutisë së bardhë, testimi i integrimeve është një testim i kutisë së zezë. (Ka edhe variante të testimit të brendshëm të thelluar.) Kjo kornizë është krijuar për të marrë një program të plotë Pulumi dhe për të kryer operacione të ndryshme në ciklin e jetës, si vendosja e një steka të ri nga zeroja, përditësimi i tij me variacione dhe fshirja, ndoshta disa herë. Ne i kryejmë ato rregullisht (p.sh. natën) dhe si teste stresi.
(Ne për të siguruar që mundësi të ngjashme për testimin e integrimeve të jenë edhe në SDK-në e gjuhëve vendase. Ju mund të përdorni kornizën e testimit të integrimeve Go të pavarur nga gjuhët në të cilat është shkruar programi juaj Pulumi).
Duke ekzekutuar programin me këtë kornizë, mund të kontrolloni sa vijon:
- Kodi i projektit tuaj është sintaksikisht i saktë dhe punon pa gabime.
- Cilësimet e konfigurimit të stekës dhe sekreteve funksionojnë dhe interpretohen siç duhet.
- Projekti juaj mund të vendoset me sukses në ofruesin tuaj të preferuar të cloud.
- Projekti juaj mund të përditësohet me sukses nga gjendja fillestare në N gjendje të tjera.
- Projekti juaj mund të shkatërrohet dhe eliminohet me sukses nga ofruesi juaj i cloud.
Siç do të shohim së shpejti, kjo kornizë mund të përdoret gjithashtu për të kryer validimin në kohë të ekzekutimit.
Një test i thjeshtë i integrimeve
Për ta parë këtë në veprim, do të shohim depozitën pulumi/examples, pasi ekipi ynë dhe komuniteti Pulumi, e përdorin atë për të testuar kërkesat e veta, angazhimet dhe ndërtimet e natës.
Më poshtë është një test i thjeshtuar i :
example_test.go:
paket 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 nëpër ciklin bazik të jetës, krijimit, ndryshimit dhe shkatërrimit të stekës për folderin aws-js-s3-folder. Do të zgjasë rreth një minutë për të raportuar testin e kaluar:
$ go test .
PASS
ok ... 43.993s Ka shumĂ« parametra pĂ«r tĂ« konfiguroni sjelljen e kĂ«tyre testeve. Lista e plotĂ« e opsioneve Ă«shtĂ« ProgramTestOptions. PĂ«r shembull, mund tĂ« konfiguroni pikĂ«n e fundjavĂ«s sĂ« Jaeger pĂ«r gjurmimin (Gjurmimi), tĂ« specifikoni se prisni dĂ«shtimin e testit gjatĂ« testimit negativ (Pritet dĂ«shtimi), tĂ« aplikoni njĂ« seri ândryshimeshâ nĂ« program pĂ«r kalimin e pjesshĂ«m tĂ« gjendjeve (EditDirs) dhe shumĂ« mĂ« tepĂ«r. Le tĂ« shohim se si t'i pĂ«rdorim ato pĂ«r tĂ« kontrolluar vendosjen e aplikacionit.
Kontrolli i pronave të burimeve
Integrimi, i cili u pĂ«rmend mĂ« parĂ«, siguron qĂ« programi ynĂ« «punon» â nuk dĂ«shton. Por çfarĂ« nĂ«se duam tĂ« verifikojmĂ« pronat e stekĂ«s qĂ« kemi marrĂ«? PĂ«r shembull, se disa lloje burimesh u krijuan (ose nuk u krijuan) dhe qĂ« ato kanĂ« disa atributet tĂ« caktuara.
Parametri ExtraRuntimeValidation për ProgramTestOptions na lejon të shohim gjendjen, të regjistruar nga Pulumi pas vendosjes (gjendja pas-vendosjes), në mënyrë që të mund të bëjmë kontrollime shtesë. Kjo përfshin një pamje të plotë të gjendjes së stekës rezultuese, përfshirë konfigurimin, vlerat e dalura të eksportuara, të gjitha burimet dhe vlerat e tyre të pronave, si dhe të gjitha varësitë midis burimeve.
Për të parë një shembull bazik të kësaj, le të verifikojmë 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, "Pritejme të gjejmë një AWS S3 Bucket")
},
})Tani, kur do të ekzekutojmë go test, ai jo vetëm që do të kalojë përmes një baterie testesh të ciklit të jetës, por gjithashtu, pas një implementimi të suksesshëm të stack-ut, do të kryejë një verifikim shtesë të gjendjes së rezultatit.
Testet e kohës së ekzekutimit
Derisa tani tĂ« gjitha testet ishin ekskluzivisht rreth sjelljes gjatĂ« implementimit dhe modelit tĂ« resursit Pulumi. ĂfarĂ« tĂ« bĂ«jmĂ« nĂ«se duam tĂ« verifikojmĂ« se infrastruktura jonĂ« e pĂ«rgatitur funksionon nĂ« tĂ« vĂ«rtetĂ«? PĂ«r shembull, qĂ« makina virtuale funksionon, S3 bucket pĂ«rmban atĂ« qĂ« presim, e kĂ«shtu me radhĂ«.
Mund të keni kuptuar tashmë 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ë pikë, ju ekzekutoni një test të rastësishëm Go me qasje në gjendjen e plotë të resurseve të programit tuaj. Kjo gjendje përfshin informacione si adresat IP të makinave virtuale, URL-të dhe gjithë atë që nevojitet për ndërveprimin real me aplikacionet dhe infrastrukturën cloud të marra.
Për shembull, programi ynë testues eksporton pronën webEndpoint të bucket-it të quajtur websiteUrl, i cili paraqet një URL të plotë për të cilën ne mund të marrim dokumentin index. Megjithatë, mund të thellojmë në skedarin e gjendjes për të gjetur bucket dhe ta lexojmë këtë pronë drejtpërdrejt, por në shumë raste stekat tona eksportojnë prona të vlefshme, si kjo, të cilat na janë të dobishme për verifikimin:
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!")
},
}) Si testet tona tĂ« mĂ«parshme tĂ« kohĂ«s sĂ« ekzekutimit, ky verifikim do tĂ« ekzekutohet menjĂ«herĂ« pas ngritjes sĂ« stack-ut, dhe tĂ« gjitha kĂ«to nĂ« pĂ«rgjigje tĂ« njĂ« thirje tĂ« thjeshtĂ« go test. Dhe ky Ă«shtĂ« vetĂ«m maja e akullit â tĂ« gjitha mundĂ«sitĂ« testuese tĂ« Go janĂ« tĂ« disponueshme qĂ« ju mund tĂ« shkruani nĂ« kod.
Integrimi i vazhdueshëm të infrastrukturës
ĂshtĂ« e mirĂ« tĂ« kesh mundĂ«sinĂ« pĂ«r tĂ« ekzekutuar teste nĂ« laptop, kur bĂ«hen shumĂ« ndryshime nĂ« infrastrukturĂ«, pĂ«r t'i verifikuar ato pĂ«rpara se tĂ« dĂ«rgohen pĂ«r shqyrtim tĂ« kodit. Por ne dhe shumĂ« nga klientĂ«t e tanĂ« testojmĂ« infrastrukturĂ«n nĂ« faza tĂ« ndryshme tĂ« ciklit tĂ« zhvillimit:
- Në çdo kërkesë pull-i të hapur për testim para bashkimit.
- Në përgjigje të çdo komenti, për të verifikuar se bashkimi u krye siç duhet.
- Periodicisht, për shembull, natën ose çdo javë për testim të shtuar.
- Në kuadër të testeve të performancës ose testeve stresuese, të cilat zakonisht kryhen për një kohë të gjatë dhe ekzekutojnë teste paralelisht dhe/ose implementojnë të njëjtin program disa herë.
Për çdo një prej tyre, Pulumi mbështet integrimin me sistemin tuaj të preferuar të integrimit të vazhdueshëm. Me integrimin e vazhdueshëm, kjo ju ofron mbulimin e testeve për infrastrukturën tuaj, si për softuerin aplikativ.
Në Pulumi ka mbështetje për sistemet e njohura CI. Ja disa prej tyre:
Për më shumë detaje, ju lutemi referojuni dokumentacionit për .
Mjediset efemere
Një mundësi shumë e fuqishme që hapet është mundësia për të implementuar mjedise efemere ekskluzivisht për qëllime testimi të pranimit. Koncepti i Pulumi është ndërtuar në mënyrë që të lehtësojë implementimin dhe shkatërrimin e mjediseve të plota dhe të izoluar, gjithçka me disa komanda të thjeshta CLI ose përmes kornizës së testimit të integrimit.
Nëse përdorni GitHub, Pulumi ofron , e cila do t'ju ndihmojë të lidheni testimin e pranimit me kërkesat pull brenda pipeline-it tuaj CI. Thjesht instaloni aplikacionin në repositorin e GitHub, dhe Pulumi në CI-në tuaj dhe informacioni mbi parashikimin e infrastrukturës, azhurnimet dhe rezultatet e testeve do të shtohen në kërkesat pull:
Duke përdorur Pulumi për testet tuaja të pranimit, do të keni mundësi të reja automatizimi që do të përmirësojnë efikasitetin e ekipit dhe do të japin siguri për cilësinë e ndryshimeve.
PĂ«rfundimi
Në këtë artikull ne pamë se, duke përdorur gjuhët e programimit të përgjithshme, na bëhen të arritshme shumë metoda për zhvillimin e softuerit, të cilat ishin të dobishme për ndërtimin e aplikacioneve tona. Ato përfshijnë testimin modular, testimin e integratës, si dhe ndërveprimin e tyre për të kryer testime të gjera në kohë reale. Testet fillojnë lehtësisht sipas kërkesës ose në sistemin tuaj CI.
Pulumi â njĂ« software me burim tĂ« hapur, qĂ« Ă«shtĂ« falas pĂ«r t'u pĂ«rdorur dhe punon me gjuhĂ«t tuaja tĂ« preferuara tĂ« programimit dhe me cloud-in tuaj â !
â
Burimi: habr.com
