Introduksjon til Serenity BDD

1. Introduksjon

I denne opplæringen vil vi gi en introduksjon til Serenity BDD - et flott verktøy for å bruke Behavior Driven Development (BDD). Dette er en løsning for automatisert akseptantesting som genererer godt illustrerte testrapporter.

2. Kjernekonsepter

Konseptene bak Serenity følger konseptene bak BDD. Hvis du vil lese mer om det, kan du sjekke artikkelen vår om Agurk og JBehave.

2.1. Krav

I Serenity er kravene organisert i tre nivåer:

evner
funksjoner
historier

Vanligvis implementerer et prosjekt funksjoner på høyt nivå, f.eks. ordrestyring og medlemsstyringsfunksjoner i et e-handelsprosjekt. Hver funksjon består av mange funksjoner, og funksjoner blir forklart i detalj av brukerhistorier.

2.2. Trinn og tester

Trinn inneholder en gruppe ressursmanipuleringsoperasjoner. Det kan være en handling, bekreftelse eller en kontekstrelatert operasjon. Det klassiske Gitt_Når_Da formatet kan gjenspeiles i trinnene.

Og tester går hånd i hånd med Fremgangsmåte.Hver test forteller en enkel brukerhistorie, som utføres ved bruk av visse Steg.

2.3. Rapporter

Serenity rapporterer ikke bare testresultatene, men bruker dem også til å produsere levende dokumentasjon som beskriver kravene og applikasjonsatferd.

3. Testing med SerenityBDD

For å kjøre Serenity-testene våre med JUnit, må vi @RunWith de SerenityRunner, testløper. SerenityRunner instrumenterer trinnbibliotekene og sørger for at testresultatene blir registrert og rapportert av Serenity-reporterne.

3.1. Maven avhengigheter

For å gjøre bruk av Serenity med JUnit, bør vi inkludere stillhet-kjerne og stillhet-junit i pom.xml:

 net.serenity-bdd serenity-core 1.2.5-rc.11 net.serenity-bdd serenity-junit 1.2.5-rc.11

Vi trenger også serenity-maven-plugin å ha rapporter samlet fra testresultater:

 net.serenity-bdd.maven.plugins serenity-maven-plugin 1.2.5-rc.6 stillhet-rapporter etter integrasjon-test aggregat

Hvis vi vil at Serenity skal generere rapporter, selv om det er en testfeil, kan du legge til følgende i pom.xml:

 org.apache.maven.plugins maven-surefire-plugin 2.20 true

3.2. Et medlemskappoengeksempel

I utgangspunktet er testene våre basert på den typiske medlemskapspoengfunksjonen i et e-handelsprogram. En kunde kan bli med i medlemsprogrammet. Når kunden kjøper varer på plattformen, vil medlemspoengene øke, og kundens medlemsgrad vil vokse tilsvarende.

La oss nå skrive flere tester mot scenariene beskrevet ovenfor og se hvordan Serenity fungerer.

La oss først skrive testen for initialisering av medlemskap og se hvilke trinn vi trenger:

@RunWith (SerenityRunner.class) offentlig klasse MemberStatusIntegrationTest {@Steps private MemberStatusSteps memberSteps; @Test offentlige ugyldige medlemmerShouldStartWithBronzeStatus () {memberSteps.aClientJoinsTheMemberProgram (); memberSteps.theMemberShouldHaveAStatusOf (Bronze); }}

Deretter implementerer vi de to trinnene som følger:

offentlig klasse MemberStatusSteps {privat medlem medlem; @Step ("Gitt et medlem har {0} poeng") offentlig ugyldig aMemberHasPointsOf (int poeng) {medlem = Member.withInitialPoints (poeng); } @Step ("Da skal medlemskarakteren være {0}") offentlig ugyldig theMemberShouldHaveAStatusOf (MemberGrade grade) {assertThat (member.getGrade (), equalTo (grade)); }}

Nå er vi klare til å kjøre en integrasjonstest med mvn ren bekreft. Rapportene vil bli lokalisert på mål / nettsted / stillhet / indeks.html:

Fra rapporten kan vi se at vi bare har en akseptantest 'Medlemmer skal begynne med bronsestatus, har evnen til' og går. Ved å klikke på testen illustreres trinnene:

Som vi kan se, gir Serenitys rapport oss en grundig forståelse av hva applikasjonen vår gjør, og om den samsvarer med våre krav. Hvis vi har noen trinn å implementere, kan vi merke dem som @Avventer:

@Pending @Step ("Når medlemmet bytter {}") offentlig ugyldig aMemberExchangeA (råvare) {// TODO}

Rapporten vil minne oss om hva som må gjøres videre. Og i tilfelle en test mislykkes, kan den også sees i rapporten:

Hvert mislykket, ignorert eller hoppet over trinn vises henholdsvis:

4. Integrasjon med JBehave

Serenity kan også integreres med eksisterende BDD-rammer som JBehave.

4.1. Maven avhengigheter

Å integrere med JBehave, en avhengighet til stillhet-jbehave er nødvendig i POM:

 net.serenity-bdd stillhet-jbehave 1.24.0

4.2. JBehave Github REST API Test fortsatte

Når vi har introdusert hvordan vi gjør REST API-testing med JBehave, kan vi fortsette med vår JBehave REST API-test og se hvordan den passer i Serenity.

Historien vår var:

Scenario: Github-brukerens profil skal ha en påloggingsnyttelast som brukernavn Gitt github-brukerprofil api Når jeg ser etter eugenp via api Da inneholder githubs svar en 'login' nyttelast som eugenp

De Gitt_Når_Da trinn kan overføres til as @Strinn uten endringer:

offentlig klasse GithubRestUserAPISteps {private String api; privat GitHubUser-ressurs; @Step ("Gitt github REST API for brukerprofil") offentlig ugyldig medUserProfileAPIEndpoint () {api = "//api.github.com/users/%s"; } @Step ("Når du leter etter {0} via api") offentlig tomrom getProfileOfUser (streng brukernavn) kaster IOException {HttpResponse httpResponse = getGithubUserProfile (api, brukernavn); ressurs = retrieveResourceFromResponse (httpResponse, GitHubUser.class); } @Step ("Da bør det være et påloggingsfelt med verdien {0} i nyttelasten til brukeren {0}") public void profilePayloadShouldContainLoginValue (String username) {assertThat (username, Matchers.is (resource.getLogin ())); }}

For å få JBehaves kartlegging av historie til kode til å fungere som forventet, må vi implementere JBehaves trinndefinisjon ved hjelp av @Strinn:

offentlig klasse GithubUserProfilePayloadStepDefinitions {@Steps GithubRestUserAPISteps userAPISteps; @Given ("github brukerprofil api") offentlig ugyldig givenGithubUserProfileApi () {userAPISteps.withUserProfileAPIEndpoint (); } @When ("ser etter $ bruker via api") offentlig ugyldig nårLookingForProfileOf (strengbruker) kaster IOException {userAPISteps.getProfileOfUser (bruker); } @Then ("githubs svar inneholder en" login "nyttelast som $ bruker") offentlig ugyldig thenGithubsResponseContainsAloginPayloadSameAs (strengbruker) {userAPISteps.profilePayloadShouldContainLoginValue (bruker); }}

Med SerenityStories, kan vi kjøre JBehave-tester både fra IDE og i byggeprosessen:

importer nett.serenitybdd.jbehave.SerenityStory; offentlig klasse GithubUserProfilePayload utvider SerenityStory {}

Etter bekrefte bygg ferdig, kan vi se testrapporten vår:

Sammenlignet med rapport fra JBehave i ren tekst, gir den rike rapporten fra Serenity oss en mer gledelig og levende oversikt over historien vår og testresultatet.

5. Integrasjon med REST-forsikret

Det er bemerkelsesverdig at Serenity støtter integrasjon med REST-forsikret. For å få en gjennomgang av REST-forsikret, ta en titt på guiden til REST-forsikret.

5.1. Maven avhengigheter

For å gjøre bruk av REST-assured med Serenity, er ro-trygg avhengighet bør inkluderes:

 net.serenity-bdd stillhet-forsikret 1.2.5-rc.11

5.2. Bruk REST-forsikret i Github REST API Test

Nå kan vi erstatte vår webklient med REST-sikre verktøy:

importer statisk nett.serenitybdd.rest.SerenityRest.rest; importer statisk nett.serenitybdd.rest.SerenityRest.then; offentlig klasse GithubRestAssuredUserAPISteps {private String api; @Step ("Gitt github REST API for brukerprofil") offentlig ugyldig medUserProfileAPIEndpoint () {api = "//api.github.com/users/{username}"; } @Step ("Når du leter etter {0} via api") offentlig ugyldig getProfileOfUser (String brukernavn) kaster IOException {rest (). Get (api, brukernavn); } @Step ("Da skal det være et påloggingsfelt med verdien {0} i nyttelasten til brukeren {0}") public void profilePayloadShouldContainLoginValue (String username) {then (). Body ("login", Matchers.equalTo (username) ); }}

Etter å ha erstattet implementeringen av brukerAPIStrinn i StepDefition, kan vi kjøre bekrefte bygge:

offentlig klasse GithubUserProfilePayloadStepDefinitions {@Steps GithubRestAssuredUserAPISteps userAPISteps; // ...}

I rapporten kan vi se den faktiske API-en som ble påkalt under testen, og ved å klikke på REST-spørring knappen, vil detaljene om forespørsel og svar bli presentert:

6. Integrasjon med JIRA

Fra nå av har vi allerede en flott testrapport som beskriver detaljer og status for våre krav med Serenity-rammeverket. Men for et smidig team brukes ofte sporingssystemer som JIRA for å holde styr på kravene. Det ville være bedre om vi kunne bruke dem sømløst.

Heldigvis støtter Serenity allerede integrasjon med JIRA.

6.1. Maven avhengigheter

For å integrere med JIRA trenger vi en annen avhengighet: stillhet-jira-krav-leverandør.

 net.serenity-bdd serenity-jira-krav-leverandør 1.1.3-rc.5

6.2. Enveis integrasjon

For å legge til JIRA-lenker i historien, kan vi legge til JIRA-problemet ved hjelp av historiens metakode:

Meta: @utgave # BDDTEST-1

Dessuten bør JIRA-konto og lenker spesifiseres i filen serenity.properties ved roten til prosjektet:

jira.url = jira.project = jira.username = jira.password =

Deretter ville det være en JIRA-lenke vedlagt i rapporten:

Serenity støtter også toveis integrasjon med JIRA, vi kan referere til den offisielle dokumentasjonen for mer informasjon.

7. Oppsummering

I denne artikkelen introduserte vi Serenity BDD og flere integrasjoner med andre testrammer og kravstyringssystemer.

Selv om vi har dekket det meste av hva Serenity kan gjøre, kan det absolutt gjøre mer. I vår neste artikkel skal vi dekke om hvordan Serenity med WebDriver-støtte kan gjøre det mulig for oss å automatisere nettsøknadssider ved hjelp av manus.

Som alltid kan den fullstendige implementeringskoden finnes på GitHub-prosjektet.

streamalism.org