streamalism.org

1. Oversikt

I denne artikkelen introduserer vi TestNG-testrammeverket.

Vi vil fokusere på: rammeverkoppsett, skriving av enkel testtilfelle og konfigurasjon, testutførelse, generering av testrapporter og samtidig utføring av test.

2. Oppsett

La oss starte med å legge til Maven-avhengigheten i vår pom.xml fil:

 org.testng testng 7.1.0 test 

Den siste versjonen finner du i Maven-depotet.

Når du bruker Eclipse, kan TestNG-pluginet lastes ned og installeres fra Eclipse Marketplace.

3. Skrive en prøvesak

For å skrive en test ved hjelp av TestNG, trenger vi bare å kommentere testmetoden med org.testng.annotations.Test kommentar:

@Test offentlig ugyldighet givenNumber_whenEven_thenTrue () {assertTrue (number% 2 == 0); }

4. Test konfigurasjoner

Mens vi skriver testtilfeller, må vi ofte utføre noen konfigurasjons- eller initialiseringsinstruksjoner før testutførelser, og også litt opprydding etter at testene er fullført. TestNG tilbyr en rekke initialiserings- og oppryddingsfunksjoner på nivå på metode, klasse, gruppe og suite:

@BeforeClass offentlig ugyldig oppsett () {number = 12; } @AfterClass offentlig ugyldighet tearDown () {number = 0; }

De oppsett () metoden kommentert med @BeforeClass merknader vil bli påkalt før gjennomføring av noen av metodene i den testklassen, og rive ned() etter gjennomføring alle metodene i testklassen.

På samme måte kan vi bruke @BeforeMethod, @AfterMethod, @ Before / AfterGroup, @ Before / AfterTest og @ Before / AfterSuite merknader for enhver konfigurasjon på metode-, gruppe-, test- og suite-nivå.

5. Testutførelse

Vi kan kjøre testsakene med Mavens “test” -kommando, den vil utføre alle testsakene som er merket med @Test sette dem til en standard testpakke. Vi kan også kjøre testtilfeller fra XML-filer fra TestNG test suite, ved å bruke maven-surefire-plugin:

 org.apache.maven.plugins maven-surefire-plugin 2.19.1 src \ test \ resources \ test_suite.xml 

Merk at hvis vi har flere XML-filer som dekker alle testtilfeller, kan vi legge til alle i suiteXmlFiles stikkord:

  src / test / resources / parametrized_test.xml src / test / resources / registration_test.xml 

For å kunne kjøre den frittstående testen, må vi ha TestNG-biblioteket i klassestien og den kompilerte testklassen sammen med XML-konfigurasjonsfilen:

java org.testng.TestNG test_suite.xml

6. Grupperingstester

Tester kan kjøres i grupper, for eksempel kan av 50 testsaker 15 grupperes sammen og utføres, slik at andre blir liggende.

I TestNG gjøres grupperingstester i suiter ved hjelp av XML-fil:

Legg merke til at begge testklassene RegistrationTest, SignInTest tilhører nå den samme suiten, og når suiten er kjørt, blir testsaker i denne klassen henrettet.

Bortsett fra testserier, kan vi også opprette testgrupper i TestNG, der metoder i stedet for testklasser er gruppert sammen. For å gjøre det, legg til grupper parameter i @Test kommentar:

@Test (grupper = "regresjon") offentlig tomrom gittNegativeNumber_sumLessthanZero_thenCorrect () {int sum = numbers.stream (). Reduser (0, Heltall :: sum); assertTrue (sum <0); }

La oss bruke en XML til å utføre gruppene:

Dette vil utføre testmetoden merket med gruppen regresjon, i SummationServiceTest klasse.

7. Parameteriserte tester

Parameteriserte enhetstester brukes til å teste den samme koden under flere forhold. Ved hjelp av parametriserte enhetstester kan vi sette opp en testmetode som innhenter data fra noen datakilde. Hovedideen er å gjøre enhetstestmetoden gjenbrukbar og å teste med et annet sett med innganger.

I TestNG kan vi parametrere tester ved hjelp av @Parameter eller @DataProvider kommentar. Når du bruker XML-filen, kan du kommentere testmetoden med @Parameter:

@Test @Parameters ({"value", "isEven"}) public void givenNumberFromXML_ifEvenCheckOK_thenCorrect (int value, boolean isEven) {assertEquals (isEven, value% 2 == 0); }

Og gi dataene ved hjelp av XML-fil:

Å bruke data fra XML-filer er nyttig, men vi trenger ofte mer komplekse data. @DataProvider kommentar brukes til å håndtere disse scenariene, som kan brukes til å kartlegge komplekse parametertyper for testmetoder.@DataProvider for primitive datatyper:

@DataProvider (name = "numbers") offentlig statisk Object [] [] evenNumbers () {return new Object [] [] {{1, false}, {2, true}, {4, true}}; } @Test (dataProvider = "numbers") public void givenNumberFromDataProvider_ifEvenCheckOK_thenCorrect (Heltall, forventet boolsk) {assertEquals (forventet, nummer% 2 == 0); }

@DataProviderfor gjenstander:

@Test (dataProvider = "numbersObject") public void givenNumberObjectFromDataProvider_ifEvenCheckOK_thenCorrect (EvenNumber number) {assertEquals (number.isEven (), number.getValue ()% 2 == 0); } @DataProvider (name = "numbersObject") public Object [] [] parameterProvider () {return new Object [] [] {{new EvenNumber (1, false)}, {new EvenNumber (2, true)}, {new EvenNumber (4, sant)}}; }

Ved hjelp av dette kan ethvert objekt som må testes opprettes og brukes i testen. Dette er mest nyttig for integrasjonstestsaker.

8. Ignorer testtilfeller

Noen ganger ønsker vi ikke å utføre en bestemt testsak, midlertidig under utviklingsprosessen. Dette kan gjøres å legge til aktivert= falsk, i @Test kommentar:

@Test (aktivert = falsk) offentlig ugyldighet givenNumbers_sumEquals_thenCorrect () {int sum = numbers.stream.reduce (0, Integer :: sum); assertEquals (6, sum); }

9. Avhengige tester

La oss vurdere et scenario, der hvis den første testsaken mislykkes, skal alle påfølgende testsaker utføres, og heller merkes som hoppet over. TestNG gir denne funksjonen med avhenger av metoder parameteren til @Test kommentar:

@Test offentlig ugyldighet gittEmail_ifValid_thenTrue () {boolean valid = email.contains ("@"); assertEquals (valid, true); } @Test (dependsOnMethods = {"givenEmail_ifValid_thenTrue"}) offentlig ugyldig givenValidEmail_whenLoggedIn_thenTrue () {LOGGER.info ("E-post {} gyldig >> pålogging", e-post); }

Legg merke til at påloggingsprøvesaken avhenger av e-postvalideringstestsaken. Dermed, hvis e-postvalidering mislykkes, vil innloggingstesten hoppes over.

10. Samtidig testutførelse

TestNG lar tester kjøre i parallell eller i flertrådet modus, og gir dermed en måte å teste disse flertrådede kodebitene på.

Du kan konfigurere, slik at metoder, klasser og suiter skal kjøres i sine egne tråder, og reduserer den totale gjennomføringstiden.

10.1. Kurs og metoder parallelt

For å kjøre testklasser parallelt, nevn parallell attributt i suite tag i XML-konfigurasjonsfil, med verdi klasser:

Merk at hvis vi har flere test i XML-filen, kan disse testene også kjøres parallelt, ved å nevne parallell = ”tester”. Også for å utføre individuelle metoder parallelt, nevn parallell = ”metoder”.

10.2. Flertrådet gjennomføring av testmetode

La oss si at vi må teste oppførselen til en kode når vi kjører i flere tråder. TestNG lar deg kjøre en testmetode i flere tråder:

offentlig klasse MultiThreadedTests {@Test (threadPoolSize = 5, invocationCount = 10, timeOut = 1000) public void givenMethod_whenRunInThreads_thenCorrect () {int count = Thread.activeCount (); assertTrue (count> 1); }}

De threadPoolSize indikerer at metoden vil kjøre inn n antall tråder som nevnt. De invocationCount og pause angi at testen vil bli utført flere ganger og mislykkes testen hvis det tar mer tid.

11. Funksjonstesting

TestNG kommer med funksjoner som også kan brukes til funksjonell testing. I forbindelse med Selen kan den enten brukes til å teste funksjonaliteten til en webapplikasjon eller brukes til å teste webtjenester med HttpClient.

Mer informasjon om funksjonstesting med Selen og TestNG er tilgjengelig her. Også noen flere ting på integrasjonstesting i denne artikkelen.

12. Konklusjon

I denne artikkelen tok vi en rask titt på hvordan du konfigurerer TestNG og utfører en enkel testtilfelle, genererer rapporter, samtidig utføring av testtilfeller og også litt om funksjonell programmering. For flere funksjoner som avhengige tester, ignorering av testtilfeller, testgrupper og suiter, kan du se vår JUnit vs TestNG-artikkel her.

Implementeringen av alle kodebitene finner du på Github.