Dag Allemaal. Vandaag delen we het laatste deel van het artikel met u. , waarvan de vertaling speciaal voor cursisten is gemaakt .
Implementatie testen
Deze manier van testen is een krachtige aanpak en stelt ons in staat white box-testen uit te voeren om de interne werking van onze infrastructuurcode te testen. Het beperkt echter enigszins wat we kunnen testen. De tests worden uitgevoerd op basis van het in-memory implementatieplan dat door Pulumi is gemaakt vóór de daadwerkelijke implementatie en daarom kan de implementatie zelf niet worden getest. Voor dergelijke gevallen heeft Pulumi een integratietestframework. En deze twee benaderingen werken uitstekend samen!
Het Pulumi-testframework voor integratie is geschreven in Go, waarmee we het grootste deel van onze interne code testen. Terwijl de eerder besproken unit-testaanpak meer leek op white box-testen, is integratietesten een black box. (Er zijn ook opties voor rigoureuze interne tests.) Dit raamwerk is gemaakt om een compleet Pulumi-programma te gebruiken en er verschillende levenscyclusbewerkingen op uit te voeren, zoals het helemaal opnieuw implementeren van een nieuwe stapel, het bijwerken met variaties en het verwijderen ervan, mogelijk meerdere keren. . We voeren ze regelmatig uit (bijvoorbeeld 's nachts) en als stresstests.
(Wij , zodat vergelijkbare mogelijkheden voor integratietests beschikbaar zijn in de native SDK van talen. U kunt het Go-integratietestframework gebruiken, ongeacht de taal waarin uw Pulumi-programma is geschreven).
Door het programma uit te voeren met behulp van dit raamwerk kunt u het volgende controleren:
- Uw projectcode is syntactisch correct en werkt zonder fouten.
- De configuratie-instellingen voor de stapel en geheimen werken en worden correct geïnterpreteerd.
- Uw project kan succesvol worden ingezet bij de cloudprovider van uw keuze.
- Uw project kan met succes worden geüpgraded van de oorspronkelijke staat naar N andere staten.
- Uw project kan succesvol worden vernietigd en verwijderd van uw cloudprovider.
Zoals we binnenkort zullen zien, kan dit raamwerk ook worden gebruikt om runtime-validatie uit te voeren.
Eenvoudige integratietest
Om dit in actie te zien, kijken we naar de repository pulumi/examples, omdat ons team en de Pulumi-gemeenschap het gebruiken om onze eigen pull-requests, commits en nachtelijke builds te testen.
Hieronder vindt u een vereenvoudigde test van onze :
voorbeeld_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 maken, wijzigen en vernietigen van een stapel voor een map aws-js-s3-folder. Het duurt ongeveer een minuut om een geslaagde test te melden:
$ go test .
PASS
ok ... 43.993s
Er zijn veel opties om het gedrag van deze tests aan te passen. Bekijk de volledige lijst met opties. ProgramTestOptions. U kunt het Jaeger-eindpunt bijvoorbeeld configureren om te traceren (Tracing), geef aan dat u verwacht dat de test mislukt als de test negatief is (ExpectFailure), een reeks “bewerkingen” op het programma toepassen voor een opeenvolgende overgang van toestanden (EditDirs) en nog veel meer. Laten we eens kijken hoe u ze kunt gebruiken om uw toepassingsimplementatie te testen.
Resource-eigenschappen controleren
De hierboven besproken integratie zorgt ervoor dat ons programma “werkt” en niet crasht. Maar wat als we de eigenschappen van de resulterende stapel willen controleren? Bijvoorbeeld dat bepaalde typen bronnen wel (of niet) zijn ingericht en dat ze bepaalde kenmerken hebben.
Parameter ExtraRuntimeValidation voor ProgramTestOptions stelt ons in staat om te kijken naar de status na de inzet die door Pulumi is geregistreerd, zodat we aanvullende controles kunnen uitvoeren. Dit omvat een volledige momentopname van de status van de resulterende stapel, inclusief configuratie, geëxporteerde uitvoerwaarden, alle bronnen en hun eigenschapswaarden, en alle afhankelijkheden tussen bronnen.
Laten we, om hiervan een eenvoudig voorbeeld te zien, controleren of ons programma er een maakt S3-emmer:
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")
},
})Wanneer we nu de go-test uitvoeren, zal het niet alleen een reeks levenscyclustests ondergaan, maar zal het, nadat de stack succesvol is geïmplementeerd, ook een extra controle uitvoeren op de resulterende staat.
Runtime-tests
Tot nu toe gingen alle tests puur over het implementatiegedrag en het Pulumi-resourcemodel. Wat moet u doen als u wilt verifiëren dat uw ingerichte infrastructuur daadwerkelijk werkt? Dat de virtuele machine bijvoorbeeld draait, dat de S3-bucket bevat wat we verwachten, enzovoort.
Je raadt misschien al hoe je dit moet doen: optie ExtraRuntimeValidation voor ProgramTestOptions - dit is hiervoor een geweldige kans. Op dit punt voert u een aangepaste Go-test uit met toegang tot de volledige status van de bronnen van uw programma. Deze status omvat informatie zoals IP-adressen van virtuele machines, URL's en alles wat nodig is om daadwerkelijk te communiceren met de resulterende cloudapplicaties en -infrastructuur.
Ons testprogramma exporteert bijvoorbeeld de woning webEndpoint emmer gebeld websiteUrl, wat de volledige URL is waar we het geconfigureerde bestand kunnen krijgen index document. Hoewel we in het staatsdossier zouden kunnen graven om het te vinden bucket en lees die eigenschap direct, maar in veel gevallen exporteren onze stapels nuttige eigenschappen zoals deze die we handig vinden om te gebruiken voor controle:
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!")
},
})
Net als onze vorige runtime-controles wordt deze controle onmiddellijk uitgevoerd nadat de stapel is verhoogd, allemaal als reactie op een eenvoudige oproep go test. En dat is nog maar het topje van de ijsberg: elke Go-testfunctie die u in code kunt schrijven, is beschikbaar.
Continue infrastructuurintegratie
Het is goed om tests op een laptop uit te kunnen voeren wanneer er veel wijzigingen in de infrastructuur worden doorgevoerd, om deze te testen voordat u ze ter beoordeling van de code indient. Maar wij en veel van onze klanten testen infrastructuur in verschillende stadia van de ontwikkelingslevenscyclus:
- In elk open pull-verzoek om te testen vóór het samenvoegen.
- Als reactie op elke commit, om nogmaals te controleren of de samenvoeging correct is uitgevoerd.
- Periodiek, bijvoorbeeld 's nachts of wekelijks, voor aanvullende tests.
- Als onderdeel van prestatie- of stresstests, die doorgaans over een lange periode lopen en tests parallel uitvoeren en/of hetzelfde programma meerdere keren inzetten.
Voor elk hiervan ondersteunt Pulumi integratie met uw favoriete continue integratiesysteem. Met continue integratie krijgt u dezelfde testdekking voor uw infrastructuur als voor uw applicatiesoftware.
Pulumi biedt ondersteuning voor veelgebruikte CI-systemen. Hier zijn er een aantal:
Voor meer gedetailleerde informatie verwijzen wij u naar de documentatie voor .
Kortstondige omgevingen
Een zeer krachtige kans die zich voordoet, is de mogelijkheid om kortstondige omgevingen uitsluitend voor acceptatietestdoeleinden in te zetten. Concept Pulumi is ontworpen om eenvoudig 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 aan , waarmee u acceptatietests kunt koppelen aan pull-aanvragen binnen uw CI-pijplijn. Installeer gewoon de applicatie in de GitHub-repository en Pulumi voegt informatie over infrastructuurpreviews, updates en testresultaten toe aan uw CI- en poolverzoeken:
Wanneer u Pulumi gebruikt voor uw belangrijkste acceptatietests, krijgt u nieuwe automatiseringsmogelijkheden die de teamproductiviteit zullen verbeteren en u vertrouwen zullen geven in de kwaliteit van uw wijzigingen.
Totaal
In dit artikel hebben we gezien dat door het gebruik van programmeertalen voor algemene doeleinden veel softwareontwikkelingstechnieken voor ons beschikbaar komen die nuttig zijn geweest bij het ontwikkelen van onze applicaties. Ze omvatten unit-tests, integratietests en hoe ze samenwerken om uitgebreide runtime-tests uit te voeren. Tests kunnen eenvoudig op aanvraag of in uw CI-systeem worden uitgevoerd.
Pulumi - open source software, gratis te gebruiken en werkt met je favoriete programmeertalen en clouds - !
→
Bron: www.habr.com