Meny

TestNG-merknader og lyttere

testng annotations listeners

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne veiledningen forklarer de forskjellige typene av TestNG-merknader og lyttere. Du vil også lære å bruke TestNG-merknader og lyttere med eksempler:

Her vil vi kjøre et grunnleggende TestNG-program ved hjelp av TestNG-merknader og også se rollen som TestNG-lyttere og hvordan du bruker dem til testing.

=> Les gjennom Easy TestNG Training Series.

TestNG-merknader og lyttere

Hva du vil lære:

Hva er TestNG-merknader?

Dette er programmet eller forretningslogikken som brukes til å kontrollere strømmen av metoder. De spiller en veldig viktig rolle i TestNG. Disse kommentarene varierer i hvert prosjekt i henhold til kravene. Flyten av merknader forblir den samme i hvert program til tross for de forskjellige kravene.

Det finnes forskjellige typer TestNG-merknader som gjør TestNG enklere og bedre enn JUnit. Hver av disse merknadene vil kjøre på et bestemt arrangement i TestNG.

Typer av merknader i TestNG

Nedenfor er listene over merknader og deres attributter som brukes i TestNG. La oss utforske dem og bruken av dem i detalj.

Før

  • @BeforeSuite: Denne metoden vil bli utført før alle testene i suiten kjøres.
  • @BeforeTest: Denne metoden vil bli utført før hver testseksjon blir erklært i suiten.
  • @BeforeClass: Denne metoden vil bli utført før den første testmetoden i gjeldende klasse.
  • @BeforeMethod: Denne metoden vil bli utført før hver testmetode.
  • @BeforeGroups: Denne metoden vil bli utført før noen testmetode for den angitte gruppen blir nevnt.
  • @Test : Markerer en klasse eller en metode som en del av testen. Eller vi kan si at det lager en metode som testmetoden.

Etter

  • @AfterSuite: Denne metoden vil bli utført etter at alle testene i suiten er kjørt.
  • @AfterTest: Denne metoden vil bli utført etter at hver testseksjon er erklært i suiten.
  • @Etter timen: Denne metoden vil bli utført etter den siste testmetoden i klassen.
  • @AfterMethod: Denne metoden vil bli utført etter at hver testmetode er utført.
  • @AfterGroups: Denne metoden blir utført etter at den siste testmetoden i den angitte gruppen er utført.

Arbeidsflyt av merknader

Når vi kjører TestNG.xml-filen, blir TestNG-kommentarene utført i følgende sekvens:

Før suite-> Før test-> Før klasse-> Før metode-> @Test -> Etter metode-> Etter klasse-> Etter test-> Etter suite

@BeforeSuite @BeforeTest @BeforeClass @BeforeMethod @Test @AfterMethod @AfterClass @AfterTest @AfterSuite

@Test har mange andre attributter som hjelper oss med å utføre testsakene våre mer effektivt.

Nedenfor er attributttypene og beskrivelsene av dem med eksempler.

# 1) AlwaysRun: Når satt til sant, vil denne metoden kjøre selv om den avhenger av en metode som har mislyktes.

Eksempel: Test (alltid kjøre = sant)

# 2) dataProvider : Dette viser navnet på dataleverandøren for denne metoden. Den har bare attributter, dvs. navn. Vi kan bruke den når vi tester programvaren vår med flere datasett ved inngangstid eller kjøretid. Dette er også kjent som datadrevet testing. Vi kan utføre datadrevet testing ved hjelp av dette attributtet.

Eksempel: @dataProvider (name = ”TestData”)

#3) dataProviderClass : Dette attributtet lar deg spesifisere dataleverandørklassen som vil inneholde dataleverandøren som @Test-metoden skal bruke.

Eksempel: @Test (dataProvider = “Client Data Test”, dataProviderClass = ClientDetailsTest.class)

# 4) avhenger av grupper : Dette attributtet avhenger av listen over grupper, dvs. testmetoden vil starte utførelsen bare etter at de avhengige gruppene er utført.

Merk : Hvis noen av testene i gruppene som er avhengige av mislykkes, hopper den testen.

Nedenfor er eksemplet:

@Test(groups= “homepage”) public void homepageTest(){ System.out.println('Home Page displayed successfully'); } @Test(groups= “transactionspage”) Public void transactionpageTest(){ System.out.println(“Transaction Page displayed successfully”); } @Test(dependsOnGroups={“homepage”, “transactionspage”}) public void dependOnGroupTest1(){ System.out.println(“dependency tested successful”);

# 5) avhenger av metoder : Denne merknaden avhenger av listen over metoder. Dette betyr at testmetoden vil starte utførelsen bare etter at de avhengige metodene er utført.

Merk : Hvis noen av testene i avhengige metoder mislykkes, hopper den over testen.

Eksempel:

@Test public void loginTest() { System.out.println(“Login Tested Successfully”); } @Test public void homepageTest() { System.out.println(“Home Page Tested Successfully”); } @Test(dependsOnMethods={“ loginTest”, “homepageTest”}) public void smokeTest() { System.out.println(“Smoke Tests were done successfully”);

# 6) AlwaysRun = sant: Vi kan sette attributtene på en testmetode til sant, og dette vil tvinge testen til å bli utført selv om noen av testene i gruppen er avhengige av feil.

For eksempel:

@Test public void launchAppTest() { System.out.println(“Application launched Successfully”); } @Test public void loginAppTest() { System.out.println(“Application logged in Successfully”); } @Test(dependsOnMethods={“launchAppTest”, “loginAppTest”}, alwaysRun=true) public void smokeTest() { System.out.println(“Smoke Test were done successfully”); }

# 7) beskrivelse : Dette gir beskrivelsen for metoden. Generelt inneholder den et sammendrag på en linje.

Eksempel:

@Test(description = “Regression Test Summary”)

# 8) aktivert : Dette attributtet hjelper til med å spesifisere om vi vil kjøre / utføre den bestemte testmetoden i gjeldende suite / klasse eller ikke. Noen ganger ønsker vi ikke å kjøre noen få tester på grunn av noen grunner som at kravet / funksjonen ofte endres, og vi ikke ønsker å forstyrre den nåværende løpeturen for den aktuelle funksjonen.

I slike tilfeller kan vi bare ignorere / deaktivere den aktuelle testen ved å sette denne funksjonen som @Test (aktivert = usann).

Eksempel:

@Test(enabled = false) public void imageTest() {//We have disabled this test by giving enabled=false System.out.println(“Image was tested successfully()”); }

# 9) forventet unntak : Denne attributtet viser listen over unntak som testmetoden skal kaste i løpetiden. Hvis det ikke kastes noen unntak eller noe annet unntak for metoden, blir testen markert som en feil.

Eksempel:

@Test(expectedExceptions = ArithmeticException.class) public void numericTest() { int i = 1 / 0; }

# 10) grupper : Dette attributtet brukes til å spesifisere gruppene som testmetoden tilhører.

@Test(groups = {“Regression”}) Public void runRegressionTest(){ System.out.println(“test runs were successful”); }

# 11) prioritet : Dette hjelper med å prioritere testmetodene, mens standardprioriteten starter med 0 og testene utføres i stigende rekkefølge.

Eksempel:

@Test Public void launchApp(){ System.out.println(“Application was launched successfully”): } @Test (priority = 1) Public void loginApp(){ System.out.println(“Application logged in successfully”); } @Test (priority = 2) Public void checkTrans(){s System.out.println(“Checked Transactions successfully”); }

Resultater: Nedenfor er resultatene pr. Prioritet, selv om det ikke ble tildelt noe nummer til den første testen, tok den som standard prioritet som 0, og utførelsen ble gjort i stigende rekkefølge.

Bestått: launchApp
Bestått: loginApp
Bestått: checkTrans

# 12) timeout : Dette attributtet hjelper til med å spesifisere en tidsavbruddsverdi for testen (vanligvis brukt som millisekunder). Hvis testen tar mer enn den angitte tidsavbruddsverdien, blir testen markert som feil. Vi kan bruke denne tidsavbruddet til å gjøre en ytelsestest, for å sikre at metoden returnerer innen rimelig tid.

@Test(timeOut = 500) public void timeTest() throws InterruptedException { Thread.sleep(400); System.out.println(“Time test method successfully tested”); }

# 13) invocationCount : Dette attributtet hjelper til med å bestemme antall ganger en testmetode skal påberopes.

@Test(invocationCount = 5) public void loginTest() { WebDriver driver = new FirefoxDriver(); driver.get('http://www.google.com'); System.out.println('Page Title is ' + driver.getTitle()); driver.quit();

Produksjon:

Sidetittel er Google
Sidetittel er Google
Sidetittel er Google
Sidetittel er Google
Sidetittel er Google

# 14) invocationTimeOut: Dette er den maksimale tiden (antall millisekunder) som denne testen skal ta for alle innkallingsantallene. Denne metoden må brukes sammen med innkallingsmetoden, ellers vil den bli ignorert.

Eksempel:

@Test(invocationCount=4, invocationTimeOut=4000) public void loginTest(){ Thread.sleep(1000); System.Out.println(“login Test”); }

Ovennevnte eksempel viser at denne testen vil ta totalt 4 sekunder å utføre, og hver gang testen blir påkalt / kjørt, vil det ta ett sekund å utføre.

# 15) @DataProvider : Denne metoden hjelper til med å levere data til en testmetode. Først må vi erklære en metode som er kommentert av @DataProvider, og deretter bruke denne metoden i den nødvendige testmetoden ved bruk av 'DataProvider' -attributtet i @Test-merknaden.

En dataleverandør returnerer en rekke objekter, spesielt et todimensjonalt objektarray () (). Den første matrisen representerer et datasett, og den andre matrisen inneholder parametrene.

@DataProvider (name = “Test”) - Her representerer navnet dataleverandørens navn. Hvis navnet ikke er gitt, vil DataProvider-navnet automatisk settes til metodenavnet.

Eksempel:

@DataProvider(name = “Name”) public object()() credentials(){ return new object ()() { { “Mohan”, “23”}, { “Shikhar”, “30”} }; } //Now we are calling the Data Provider object by its name @Test(DataProvider = “Name”) Public void testData(String sName, int age) { System.out.println(“Data is: (Name, age)”); }

# 16) @Fabrikk : Dette brukes til å spesifisere en metode som en fabrikk for å levere objekter som skal brukes av TestNG for testklassene. Ved å bruke @Factory kan vi lage dynamiske tester i løpetid, og det skal returnere et array-objekt.

Eksempel:

La oss ta et eksempel for å forstå det bedre. Vi vil lage to klasser, dvs. FactorySample.Java og FactoryTest.Java

FactorySample.Java

public class FactorySample { @Test public void googleTest() { System.out.println(“Google was launched successfully”); } @Test public void gmailLogin() { System.out.println(“Gmail logged in successfully”); }

FactoryTest.Java

public class FactoryTest { @Factory() public Object() testFact() { FactorySample fs = new FactorySample(2); fs(0) = new googleTest(); fs(1) = new gmailLogin(); return fs; } }

Produksjon : Google ble lansert

Gmail logget på

Forskjellen mellom @Factory og @DataProvider-merknader

Det er en grunnleggende forskjell mellom begge kommentarene. Det er mye forvirring angående disse to kommentarene, som hvor du skal bruke disse og hvorfor?

La oss finne svarene.

@DataProvider: Denne kommentaren vil parameterisere den bestemte testmetoden og utføre testen i et spesifikt nei. ganger basert på data levert av denne metoden.

For eksempel, Hvis det er to parametere, vil testmetoden utføres to ganger. For eksempel, hvis vi ønsker å logge inn på et nettsted med forskjellige sett med brukernavn og passord hver gang, så er dette nyttig ettersom vi må oppgi parametrene som skal testes.

@Fabrikk : Dette vil utføre alle testmetodene som finnes i testklassefilen mens du bruker en separat forekomst av den klassen. Dette er nyttig hvis vi vil kjøre testklassen et antall ganger.

For eksempel , hvis vi må teste innloggingsfunksjonen til et hvilket som helst program eller et nettsted, og da vi må kjøre denne testen flere ganger, er det bedre å bruke @ Factory der vi kan opprette flere forekomster av test og kjøre testene.

La oss se på disse eksemplene for å vite forskjellen.

@DataProvider Eksempel :

@DataProvider public Object()() message(){ return new Object ()(){{“Mihir” , new Integer (145632)}, {“Kumar”, new Integer (28242)}}; } @Test (dataProvider=”message”) public void PrintMsg(String name, Integer id){ System.out.println(“Names are: “+name+” “+id); }

Merk : I det ovennevnte programmet har vi gitt to data, og programresultatet vil være:

Navnene er: Mihir 145632
Navnene er: Kumar 28242

Dette viser at hvis vi øker antall data i meldingsmetoden, vil utskriftsmetoden utføre samme antall ganger.

@Fabrikkeksempel :

TestNG Factory er veldig nyttig når vi må kjøre flere testklasser ved hjelp av en enkelt testklasse.

La oss se et eksempel.

For dette må vi lage to testklasser med få testmetoder inni dem.

Testdata 1:

public class TestData1 { @Test public void testData1() { System.out.println('Test data 1 successfully tested'); } }

Testdata 2:

public class TestData2 { @Test public void testData2() { System.out.println('Test data 2 successfully tested'); } }

Nå må vi definere @Factory-metoden som returnerer en objektmatrise av de ovenfor definerte klassene.

Fabrikkprogram:

public class TestNGFactory { @Factory() public Object() getTestClass() { Object() tests = new Object(2); tests(0) = new Test Data 1(); tests(1) = new Test Data 2(); return tests; } }

Produksjon:

Test1 testmetode
Test2 testmetode
PASSERT: test1
PASSERT: test2

TestNG-lyttere med typer

Enkelt sagt lytterne lytter til hendelsen som er definert i Selenium-skriptet og oppfører seg i samsvar med det. Hovedformålet er å lage logger og tilpasse TestNG-rapportene.

Det er mange typer lyttere tilgjengelig i TestNG.

For eksempel , IAnnotationTransformer, IAnnotationTransformer2, IConfigurable, IConfigurationListener, IConfigurationListener2, IExecutionListener, IHookable, IInvokedMethodListener, IInvokedMethodListener2, IMethodInterceptor, IReporter, ISuiteListener,

Men når det gjelder testing, bruker vi bare noen få av dem som diskutert nedenfor:

# 1) ISuiteListener

Dette er en lytter til testsuiter. Den består av to metoder, dvs. onStart () og onFinish () .

Hver gang vi implementerer denne lytteren, vil det garantere at sluttbrukeren vil påkalle metodene onStart () og onFinish () før og etter å ha kjørt en TestNG-suite.

Metodedetaljer:

ugyldig onStart (ISuite-suite) : Denne metoden påkalles før Suite Runner starter.

void onFinish (ISuite-suite) : Denne metoden påkalles etter at Suite Runner har kjørt alle testsuitene.

Eksempel:

@Override public void onStart(ISuite suite) { System.out.println(“TestNG Suite Starts”); } @Override public void onFinish(ISuite suite) { System.out.println(“TestNG Suite Finishes”); }

# 2) ITestListener

Denne lytteren fungerer akkurat som ISuiteListener. Den eneste forskjellen er imidlertid at den ringer før og etter testen, og ikke suiten. Det er en lytter for testkjøring, og denne lytteren har sju metoder i seg.

(i) onStart () :Denne metoden påkalles etter at testklassen er instantiert og før noen konfigurasjonsmetoder kalles.

Eksempel:

@Override public void onStart(ITestContext context) { System.out.println(“Context Name = ” + context.getName()); }

(ii) onFinish () :Denne metoden påkalles etter at alle testene har kjørt og alle konfigurasjonsmetodene kalles.

Eksempel:

public void onFinish(ITestContext context) { System.out.println(context.getPassedTests()); }

(iii) onTestStart () :Denne metoden påkalles hver gang før en test blir påkalt. ITestResult er bare delvis fylt med referanser til klasse, metode, start millis og status.

Metode: ugyldig onTestStart (ITestResult-resultat)

Eksempel:

@Override public void onTestStart(ITestResult result) { System.out.println('Test Started…'+result.getStartMillis()); }

(iv) onTestSuccess () :Denne metoden påkalles hver gang en test lykkes.

Metode: ugyldig onTestSuccess (ITestResult-resultat)

Eksempel:

@Override public void onTestSuccess(ITestResult result) { System.out.println('Test Success. '+result.getEndMillis()); }

(v) onTestFailure () :Denne metoden påkalles hver gang en test mislykkes.

Metode: ugyldig onTestFailure (ITestResult resultat)

Eksempel:

@Override public void onTestFailure(ITestResult result) { System.out.println('Test Failed. '+result.getTestName()); }

(vi) onTestSkipped() :Denne metoden påkalles hver gang en test hoppes over.

Metode: ugyldig onTestSkipped (ITestResult-resultat)

Eksempel:

@Override public void onTestSkipped(ITestResult result) { System.out.println('Test Skipped. '+result.getTestName()); }

(vii) onTestFailedButWithinSuccessPercentage :Denne metoden påkalles hver gang en metode mislykkes, men har blitt kommentert med suksessprosent, og feilen holder den innenfor suksessprosenten.

Metode: ugyldig påTestFailedButWithinSuccessPercentage (ITestResult resultat)

Eksempel:

@Override public void onTestFailedButWithinSuccessPercentage(ITestResult iTestResult) { System.out.println('Test failed but it is in defined success ratio ' + getTestMethodName(iTestResult)); }

# 3) IExecutionListener

Det er en lytter som overvåker begynnelsen og slutten av et TestNG-løp. Den har to metoder, dvs. onExecutionStart () og onExecutionFinish () .

onExecutionStart () -metoden kalles før TestNG begynner å kjøre suitene, og metoden onExecutionFinish () kalles etter at TestNG er ferdig med kjøring av alle test-suitene.

Metode:

ugyldig påExecutionStart ()

ugyldig påExecutionFinish ()

Eksempel:

@Override public void onExecutionStart() { System.out.println('TestNG is going to start'); } @Override public void onExecutionFinish() { System.out.println('TestNG is finished'); }

# 4) IInvokedMethodListener

Det er en lytter som blir påkalt før og etter at en metode blir påkalt av TestNG. Denne lytteren påkalles bare for konfigurasjoner og testmetoder. Den har bare to metoder i den, dvs. etterInvocation og beforeInvocation.

  1. før innkalling: Påkalle før hver metode.
  2. etterInvokasjon: Påkalle etter hver metode.

Metode:

ugyldig førInvocation (IInvokedMethod metode, ITestResult testResult)

ugyldig etterInvocation (IInvokedMethod-metode, ITestResult testResult)

Eksempel:

@Override public void beforeInvocation(IInvokedMethod method, ITestResult testResult) { System.out.println('before invocation of ' + method.getTestMethod().getMethodName()); } @Override public void afterInvocation(IInvokedMethod method, ITestResult testResult) { System.out.println('after invocation of ' + method.getTestMethod().getMethodName()); }

# 5) IMethodInterceptor

Denne klassen brukes til å endre listen over testmetoder som TestNG skal kjøre. Ved å bruke denne metoden kan vi omorganisere listen over testmetoder.

Det gjelder bare de metodene som ikke er avhengige, og de metodene som ikke er avhengige av andre testmetoder vil bli gitt i parametere. Dette grensesnittet returnerer en liste over testmetoder som må kjøres, men på en annen sortert måte.

Metode:

beste systemvedlikeholdsprogramvare for Windows 10

java.util.List avlyssning (java.util.List metoder, ITestContext sammenheng)

Eksempel:

@Override public Listintercept(Listmethods, ITestContext context) { List result = new ArrayList(); for (IMethodInstance m : methods) { Test test = m.getMethod().getMethod().getAnnotation(Test.class); Setgroups = new HashSet(); for (String group : test.groups()) { groups.add(group); } if (groups.contains('sanity')) { result.add(m); } else { String testMethod = m.getMethod().getMethodName(); System.out.println(testMethod + ' not a SANITY test so not included'); } } return result; }

# 6) IReporter

Dette implementeres av klientene for å generere en rapport. Denne metoden vil bli påkalt når alle suitene har kjørt, og parametrene gir alle testresultatene som skjedde under løpet.

Metode:

ugyldig generereReport (java.util.List xmlSuites, java.util.List suites, java.lang.String outputDirectory)

Eksempel:

@Override public void generateReport(List xmlSuites, List suites, String outdir) { try { writer = createWriter(outdir); } catch (IOException e) { System.err.println('Unable to create output file'); e.printStackTrace(); return; } startHtml(writer); writeReportTitle(reportTitle); generateSuiteSummaryReport(suites); generateMethodSummaryReport(suites); generateMethodDetailReport(suites); endHtml(writer); writer.flush(); writer.close(); }

Konklusjon

I denne artikkelen har vi sett hvordan TestNG-merknader kan være nyttige for å gjøre programlogikken enklere. Kommentarer brukes etter behov.

Du kan overføre parametrene til kommentarene og gjøre datadrevet testing også. Du kan kjøre testsakene i grupper og spare tid. Med lyttere kan du til og med generere rapportene. Synes du ikke dette er fantastisk?

TestNG.xml vil bli forklart i detalj i vår kommende opplæring. Denne XML-filen er ryggraden i TestNG-rammeverket, og den vil hjelpe oss med å utføre testsakene våre.

=> Sjekk ut den perfekte TestNG treningsveiledningen her.

Anbefalt lesing

^