Hallo iedereen. Vandaag delen we het laatste deel van het artikel , een vertaling die speciaal is voorbereid voor studenten van de cursus .
Deployment Testing
De besproken teststijl is een krachtig hulpmiddel, waarmee we witte-doos testen kunnen uitvoeren om de interne werking van onze infrastructuurcode te controleren. Echter, het beperkt enigszins wat we kunnen testen. Tests worden uitgevoerd op basis van een in-memory deploymentplan dat door Pulumi is gemaakt vóór de feitelijke uitrol, en daarom kan de uitrol zelf niet worden getest. Voor dergelijke gevallen heeft Pulumi een framework voor integratietests. En deze twee benaderingen werken uitstekend samen!
Het Pulumi integratietestframework is geschreven in Go, en met dit framework testen we het grootste deel van onze interne code. Terwijl de eerder besproken modulaire testbenadering meer leek op witte-doos testen, is integratietests een zwarte doos. (Er zijn ook opties voor grondige interne tests.) Dit framework is ontworpen om een volledige Pulumi-applicatie te nemen en verschillende levenscyclusoperaties uit te voeren, zoals het uitrollen van een nieuwe stack vanaf nul, deze bijwerken met variaties en verwijderen, mogelijk meerdere keren. We draaien deze regelmatig (bijvoorbeeld 's nachts) en als stresstests.
(We , zodat vergelijkbare mogelijkheden voor integratietests beschikbaar zijn in de native SDK's van talen. Je kunt het Go integratietestframework gebruiken, ongeacht de taal waarin je Pulumi-applicatie is geschreven).
Door het programma met dit framework uit te voeren, kun je het volgende controleren:
- De code van je project is syntactisch correct en werkt zonder fouten.
- De configuratie-instellingen van de stack en geheimen werken en worden correct geïnterpreteerd.
- Je project kan succesvol worden uitgerold bij de cloudprovider van jouw keuze.
- Je project kan succesvol worden geüpdatet van de initiële staat naar N andere staten.
- Je project kan succesvol worden vernietigd en verwijderd bij je cloudprovider.
Zoals we binnenkort zullen zien, kan dit framework ook worden gebruikt voor runtime-validatie.
Eenvoudige integratietest
Om dit in actie te zien, kijken we naar de repository pulumi/examples, omdat ons team en de Pulumi-gemeenschap deze gebruiken om hun eigen pull requests, commits en nachtelijke builds te testen.
Hieronder staat een vereenvoudigde test van onze :
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,
},
})
} Deze test doorloopt de basislevenscyclus van het creëren, wijzigen en vernietigen van een stack voor de folder aws-js-s3-folder. Het duurt ongeveer een minuut om een geslaagde test te rapporteren:
$ go test .
PASS
ok ... 43.993s Er zijn veel parameters beschikbaar om het gedrag van deze tests aan te passen. Een volledige lijst met opties vindt u in ProgramTestOptions. U kunt bijvoorbeeld de Jaeger-eindpunt voor tracing instellen (Tracing), aangeven dat u een falen van de test verwacht bij negatieve tests (ExpectFailure), een reeks 'wijzigingen' op het programma toepassen voor sequentiële statusovergangen (EditDirs) en nog veel meer. Laten we eens kijken hoe we deze kunnen gebruiken om de implementatie van een applicatie te controleren.
Controle van de eigenschappen van middelen
De integratie waar we het over hadden, garandeert dat ons programma 'werkt' — het crasht niet. Maar wat als we de eigenschappen van de resulterende stack willen controleren? Bijvoorbeeld, of bepaalde soorten middelen zijn (of niet zijn) prepared en dat ze bepaalde attributen hebben.
Parameter ExtraRuntimeValidation voor ProgramTestOptions stelt ons in staat om de toestand te bekijken die door Pulumi is vastgelegd na de implementatie (post-deployment state), zodat we extra controles kunnen uitvoeren. Dit omvat een volledige snapshot van de toestand van de resulterende stack, inclusief configuratie, geëxporteerde uitvoerwaarden, alle middelen en waarden van hun eigenschappen, evenals alle afhankelijkheden tussen middelen.
Om een basisvoorbeeld hiervan te zien, laten we controleren of ons programma één S3 Bucket:
integration.ProgramTest(t, &integration.ProgramTestOptions{
// zoals voorheen...
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, "Verwachtte een enkele AWS S3 Bucket te vinden")
},
})Nu, wanneer we go test uitvoeren, zal het niet alleen door de batterij van levenscyclustesten gaan, maar ook, na een succesvolle implementatie van de stack, een extra controle van de resulterende status uitvoeren.
Runtime-testen
Tot nu toe waren alle tests uitsluitend gericht op het gedrag bij implementatie en het model van Pulumi-resources. Wat als je wilt controleren of je voorbereidende infrastructuur daadwerkelijk werkt? Bijvoorbeeld, of de virtuele machine draait, of de S3-bucket bevat wat we verwachten, enzovoort.
Je hebt misschien al geraden hoe je dit kunt doen: de optie ExtraRuntimeValidation voor ProgramTestOptions is een uitstekende gelegenheid daarvoor. Op dit punt voer je een willekeurige Go-test uit met toegang tot de volledige staat van de resources van je programma. Deze staat bevat informatie zoals IP-adressen van virtuele machines, URL's en alles wat nodig is voor daadwerkelijke interactie met de verkregen cloudapplicaties en infrastructuur.
Bijvoorbeeld, ons testprogramma exporteert de eigenschap webEndpoint van de bucket met de naam websiteUrl, die de volledige URL is waarmee we het ingestelde index documentkunnen benaderen. Hoewel we in het statusbestand zouden kunnen graven om dit eigenschap rechtstreeks te vinden en te lezen, exporteren onze stacks in veel gevallen nuttige eigenschappen zoals deze die we gemakkelijk kunnen gebruiken voor verificatie: bucket integration.ProgramTest(t, &integration.ProgramTestOptions{ // zoals voorheen ... 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), "Hallo, Pulumi!") }, })
Net als onze eerdere runtime-controles, zal deze controle worden uitgevoerd onmiddellijk na het opzetten van de stack, en dit als reactie op een eenvoudige oproep go test ga testen. En dit is slechts de top van de ijsberg - alle testmogelijkheden van Go zijn beschikbaar die je in je code kunt schrijven.
Continue integratie van infrastructuur
Het is handig om tests op een laptop uit te voeren wanneer er veel wijzigingen aan de infrastructuur worden aangebracht, om ze te controleren voordat ze voor code-review worden ingediend. Maar wij en veel van onze klanten testen de infrastructuur tijdens verschillende fasen van de ontwikkelingscyclus:
- Bij elke open pull request voor testen vóór de samenvoeging.
- In reactie op elke commit, om te verifiëren dat de samenvoeging correct is uitgevoerd.
- Periodiek, bijvoorbeeld 's nachts of wekelijks voor extra tests.
- Als onderdeel van prestatie- of stress tests, die doorgaans over lange tijdsperioden worden uitgevoerd en tests parallel of dezelfde toepassing meerdere keren implementeren.
Voor elk van deze ondersteunt Pulumi integratie met jouw favoriete continue integratiesysteem. Bij continue integratie biedt dit je dezelfde testdekking voor je infrastructuur als voor je applicatiesoftware.
Pulumi heeft ondersteuning voor veel voorkomende CI-systemen. Hier zijn er enkele:
Voor meer gedetailleerde informatie, raadpleeg de documentatie over .
Ephemerale omgevingen
Een zeer krachtige mogelijkheid die zich aandient, is de mogelijkheid om ephemerale omgevingen uitsluitend voor acceptatietests te implementeren. Het concept Pulumi is ontworpen om het gemakkelijk te maken om volledig geïsoleerde en onafhankelijke omgevingen te implementeren en af te breken, allemaal met een paar eenvoudige CLI-opdrachten of met behulp van een integratietestframework.
Als je GitHub gebruikt, biedt Pulumi , dat je helpt om acceptatietests aan pull requests binnen je CI-pijplijn te koppelen. Installeer gewoon de app in de GitHub-repository, en Pulumi in je CI, en er zal informatie over de infrastructuur-preview, updates en testresultaten aan de pull requests worden toegevoegd:
Met Pulumi voor uw belangrijkste acceptatietests krijgt u nieuwe automatiseringsmogelijkheden die de productiviteit van het team verbeteren en het vertrouwen in de kwaliteit van wijzigingen vergroten.
Conclusie
In dit artikel hebben we gezien dat bij het gebruik van algemene programmeertalen veel softwareontwikkelingsmethoden beschikbaar komen die nuttig zijn bij de ontwikkeling van onze toepassingen. Deze omvatten unit testing, integratietests en hun interactie voor uitgebreid runtime-testen. Tests zijn eenvoudig op aanvraag of in uw CI-systeem uit te voeren.
Pulumi is open-source software, het is gratis te gebruiken en werkt met uw favoriete programmeertalen en clouds - !
→
Bron: habr.com
