Introduktion til Serenity BDD

1. Introduktion

I denne vejledning giver vi en introduktion til Serenity BDD - et godt værktøj til anvendelse af Behavior Driven Development (BDD). Dette er en løsning til automatiseret acceptstest, der genererer godt illustrerede testrapporter.

2. Kernebegreber

Begreberne bag Serenity følger koncepterne bag BDD. Hvis du vil læse mere om det, skal du se vores artikel om agurk og JBehave.

2.1. Krav

I Serenity er kravene organiseret i tre niveauer:

kapaciteter
funktioner
historier

Typisk implementerer et projekt funktioner på højt niveau, f.eks. ordrestyring og medlemsstyringsfunktioner i et e-handelsprojekt. Hver funktion består af mange funktioner, og funktioner forklares detaljeret af brugerhistorier.

2.2. Trin og test

Trin indeholder en gruppe ressourcemanipulationshandlinger. Det kan være en handling, verifikation eller en kontekstrelateret operation. Den klassiske Giv_Når_Derpå format kan afspejles i trinene.

Og prøver går hånd i hånd med Trin.Hver test fortæller en simpel brugerhistorie, som udføres ved hjælp af bestemte Trin.

2.3. Rapporter

Serenity rapporterer ikke kun testresultaterne, men bruger dem også til at producere levende dokumentation, der beskriver kravene og applikationsadfærd.

3. Test med SerenityBDD

For at køre vores Serenity-tests med JUnit skal vi @RunWith det SerenityRunner, testløber. SerenityRunner instrumenterer trinbibliotekerne og sikrer, at testresultaterne registreres og rapporteres af Serenity-journalisterne.

3.1. Maven afhængigheder

For at gøre brug af Serenity med JUnit, skal vi inkludere sindsro-kerne og sindsro-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 har også brug for det serenity-maven-plugin at have rapporter samlet fra testresultater:

 net.serenity-bdd.maven.plugins serenity-maven-plugin 1.2.5-rc.6 sindsro-rapporter efter integration-test-aggregat

Hvis vi ønsker, at Serenity skal generere rapporter, selvom der er en testfejl, skal du tilføje følgende til pom.xml:

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

3.2. Et medlemskabspointeksempel

Oprindeligt er vores test baseret på den typiske medlemskabsfunktion i en e-handelsapplikation. En kunde kan tilmelde sig medlemsprogrammet. Når kunden køber varer på platformen, vil medlemspointene stige, og kundens medlemskabsklasse vil vokse tilsvarende.

Lad os nu skrive flere tests mod scenarierne beskrevet ovenfor og se, hvordan Serenity fungerer.

Lad os først skrive testen til initialisering af medlemskab og se hvilke trin vi har brug for:

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

Derefter implementerer vi de to trin som følger:

offentlig klasse MemberStatusSteps {privat medlem medlem; @Step ("Givet et medlem har {0} point") offentlig ugyldighed aMemberHasPointsOf (int point) {member = Member.withInitialPoints (point); } @Step ("Så skal medlemskarakteren være {0}") offentlig ugyldigMemberShouldHaveAStatusOf (MemberGrade-karakter) {assertThat (member.getGrade (), equalTo (grade)); }}

Nu er vi klar til at køre en integrationstest med mvn ren kontrol. Rapporterne findes på target / site / serenity / index.html:

Fra rapporten kan vi se, at vi kun har en acceptstest 'Medlemmer skal starte med bronzestatus, har evnen til' og passerer. Ved at klikke på testen illustreres trinene:

Som vi kan se, giver Serenitys rapport os en grundig forståelse af, hvad vores ansøgning laver, og om det stemmer overens med vores krav. Hvis vi har nogle trin til at gennemføre, kan vi markere dem som @Verserende:

@Pending @Step ("Når medlemmet udveksler {}") annullerer offentligt aMemberExchangeA (råvare) {// TODO}

Rapporten minder os om, hvad der skal gøres næste gang. Og hvis en test mislykkes, kan den også ses i rapporten:

Hvert mislykket, ignoreret eller sprunget trin vises henholdsvis:

4. Integration med JBehave

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

4.1. Maven afhængigheder

At integrere med JBehave, en yderligere afhængighed sindsro-opfører sig er nødvendigt i POM:

 net.serenity-bdd sindsro-jbehave 1.24.0

4.2. JBehave Github REST API Test fortsat

Da vi har introduceret, hvordan man laver REST API-test med JBehave, kan vi fortsætte med vores JBehave REST API-test og se, hvordan den passer til Serenity.

Vores historie var:

Scenarie: Github-brugerens profil skal have en login-nyttelast, der er den samme som brugernavnet Givet github-brugerprofil api Når jeg leder efter eugenp via api-en, så indeholder githubs svar en 'login' -belastning, der er den samme som eugenp

Det Giv_Når_Derpå trin kan overføres til som @ Trin uden ændringer:

offentlig klasse GithubRestUserAPISteps {private String api; privat GitHubUser-ressource; @Step ("givet github REST API til brugerprofil") offentlig ugyldig medUserProfileAPIEndpoint () {api = "//api.github.com/users/%s"; } @Step ("Når du leder efter {0} via api"), offentlig ugyldig getProfileOfUser (streng brugernavn) kaster IOException {HttpResponse httpResponse = getGithubUserProfile (api, brugernavn); ressource = retrieveResourceFromResponse (httpResponse, GitHubUser.class); } @Step ("Så skal der være et loginfelt med værdien {0} i brugerens nyttelast {0}") public void profilePayloadShouldContainLoginValue (String username) {assertThat (username, Matchers.is (resource.getLogin ())); }}

For at få JBehaves historie-til-kode kortlægning til at fungere som forventet, er vi nødt til at implementere JBehaves trindefinition ved hjælp af @ Trin:

offentlig klasse GithubUserProfilePayloadStepDefinitions {@Steps GithubRestUserAPISteps userAPISteps; @Given ("github brugerprofil api") offentlig ugyldighed givenGithubUserProfileApi () {userAPISteps.withUserProfileAPIEndpoint (); } @When ("på udkig efter $ bruger via api") offentlig ugyldighed nårLookingForProfileOf (strengbruger) kaster IOException {userAPISteps.getProfileOfUser (bruger); } @Then ("githubs svar indeholder en 'login' nyttelast samme som $ bruger") offentlig ugyldig derefterGithubsResponseContainsAloginPayloadSameAs (streng bruger) {userAPISteps.profilePayloadShouldContainLoginValue (bruger); }}

Med SerenityStories, kan vi køre JBehave-test både inden for vores IDE og i byggeprocessen:

import net.serenitybdd.jbehave.SerenityStory; offentlig klasse GithubUserProfilePayload udvider SerenityStory {}

Efter verificere bygge færdig, kan vi se vores testrapport:

Sammenlignet med almindelig tekstrapport fra JBehave giver den rige rapport fra Serenity os et mere iøjnefaldende og levende overblik over vores historie og testresultatet.

5. Integration med REST-sikret

Det er bemærkelsesværdigt, at Serenity understøtter integration med REST-sikret. For at få en gennemgang af REST-sikret, se på guiden til REST-assured.

5.1. Maven afhængigheder

For at gøre brug af REST-sikret med Serenity, er sindsro-være sikker afhængighed skal medtages:

 net.serenity-bdd sindsro-hvil-sikker 1.2.5-rc.11

5.2. Brug REST-sikret i Github REST API Test

Nu kan vi erstatte vores webklient med REST-forsikrede værktøjer:

importer statisk net.serenitybdd.rest.SerenityRest.rest; importer statisk net.serenitybdd.rest.SerenityRest.then; offentlig klasse GithubRestAssuredUserAPISteps {private String api; @Step ("Gitt github REST API til brugerprofil") offentlig ugyldig medUserProfileAPIEndpoint () {api = "//api.github.com/users/{username}"; } @Step ("Når du leder efter {0} via api") offentlig tomrum getProfileOfUser (streng brugernavn) kaster IOException {rest (). Get (api, brugernavn); } @Step ("Derefter skal der være et loginfelt med værdien {0} i brugerens nyttelast {0}") public void profilePayloadShouldContainLoginValue (String username) {then (). Body ("login", Matchers.equalTo (username) ); }}

Efter at have erstattet implementeringen af brugerAPIS trin i StepDefition, kan vi køre verificere bygge:

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

I rapporten kan vi se den aktuelle API påberåbt under testen og ved at klikke på REST-forespørgsel knappen vises detaljerne om anmodning og svar:

6. Integration med JIRA

Fra nu af har vi allerede en god testrapport, der beskriver detaljer og status for vores krav med Serenity framework. Men for et smidigt team bruges ofte sporingssystemer som JIRA til at holde styr på kravene. Det ville være bedre, hvis vi kunne bruge dem problemfrit.

Heldigvis understøtter Serenity allerede integration med JIRA.

6.1. Maven afhængigheder

For at integrere med JIRA har vi brug for en anden afhængighed: stillhed-jira-krav-udbyder.

 net.serenity-bdd sindsro-jira-krav-udbyder 1.1.3-rc.5

6.2. Envejs integration

For at tilføje JIRA-links i historien kan vi tilføje JIRA-problemet ved hjælp af historiens metatag:

Meta: @udgave # BDDTEST-1

Derudover skal JIRA-konto og -link specificeres i filen serenity.properties ved projektets rod:

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

Derefter ville der være et JIRA-link tilføjet i rapporten:

Serenity understøtter også tovejsintegration med JIRA, vi kan henvise til den officielle dokumentation for flere detaljer.

7. Resume

I denne artikel introducerede vi Serenity BDD og flere integrationer med andre testrammer og kravstyringssystemer.

Selvom vi har dækket det meste af, hvad Serenity kan gøre, kan det helt sikkert gøre mere. I vores næste artikel behandler vi, hvordan Serenity med WebDriver-support kan gøre det muligt for os at automatisere webapplikationssider ved hjælp af manuskript.

Som altid kan den fulde implementeringskode findes på GitHub-projektet.

streamalism.org