Menu

TestNG-kommentarer og lyttere

testng annotations listeners

Prøv Vores Instrument Til At Fjerne Problemer

Denne vejledning forklarer de forskellige typer TestNG-kommentarer og lyttere. Du lærer også, hvordan du bruger TestNG-kommentarerne og lyttere med eksempler:

Her kører vi et grundlæggende TestNG-program ved hjælp af TestNG-kommentarer og ser også rollen som TestNG-lyttere og hvordan man bruger dem til test.

=> Læs gennem Easy TestNG Training Series.

TestNG-kommentarer og lyttere

Hvad du vil lære:

Hvad er TestNG-kommentarer?

Dette er det program eller den forretningslogik, der bruges til at kontrollere strømmen af ​​metoder. De spiller en meget vigtig rolle i TestNG. Disse kommentarer er forskellige i hvert projekt i henhold til kravene. Annotationsstrømmen forbliver den samme i hvert program på trods af de forskellige krav.

Der er forskellige typer TestNG-kommentarer, der gør TestNG nemmere og bedre end JUnit. Hver af disse bemærkninger kører ved en bestemt begivenhed i TestNG.

Typer af kommentarer i TestNG

Nedenfor er listerne over annotationer og deres attributter, der bruges i TestNG. Lad os udforske dem og deres anvendelser i detaljer.

Før

  • @BeforeSuite: Denne metode udføres, før alle testene i pakken køres.
  • @BeforeTest: Denne metode udføres, før hver testafdeling erklæres i pakken.
  • @BeforeClass: Denne metode udføres før den første testmetode i den aktuelle klasse.
  • @BeforeMethod: Denne metode udføres før hver testmetode.
  • @BeforeGroups: Denne metode udføres, før testmetoder fra den angivne gruppe nævnes.
  • @Prøve : Markerer en klasse eller en metode som en del af testen. Eller vi kan sige, at det gør en metode som testmetoden.

Efter

  • @AfterSuite: Denne metode udføres, når alle testene i pakken er kørt.
  • @AfterTest: Denne metode udføres, efter at hver testsektion er erklæret i pakken.
  • @Efter skole: Denne metode udføres efter den sidste testmetode i klassen.
  • @AfterMethod: Denne metode udføres, efter at hver testmetode er udført.
  • @AfterGroups: Denne metode udføres, efter at den sidste testmetode i den angivne gruppe er udført.

Arbejdsflow af kommentarer

Når vi udfører TestNG.xml-filen, udføres TestNG-kommentarerne i følgende rækkefølge:

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

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

@Prøve har mange andre attributter, der hjælper os med at udføre vores testsager mere effektivt.

Nedenfor er attributtyperne og deres beskrivelser med eksempler.

# 1) Kør altid: Når den er sat til sand, kører denne metode, selvom den afhænger af en metode, der er mislykket.

Eksempel: Test (altid køre = sand)

# 2) dataProvider : Dette viser navnet på dataudbyderen til denne metode. Det har kun attributter, dvs. navn. Vi kan bruge det, når vi tester vores software med flere datasæt på inputtid eller kørselstid. Dette er også kendt som datadrevet test. Vi kan udføre datadrevet test ved hjælp af denne attribut.

Eksempel: @dataProvider (name = ”TestData”)

# 3) dataProviderClass : Denne attribut giver dig mulighed for at specificere den dataudbyderklasse, der indeholder den dataudbyder, som @Test-metoden bruger.

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

# 4) afhænger af grupper : Denne attribut afhænger af listen over grupper, dvs. testmetoden starter kun udførelsen, efter at de afhængige grupper er udført.

Bemærk : Hvis nogen af ​​testene i de grupper, der er afhængige af, mislykkes, springer den testen over.

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) afhænger af metoder : Denne kommentar afhænger af listen over metoder. Dette betyder, at testmetoden kun starter udførelse, efter at de afhængige metoder er udført.

Bemærk : Hvis nogen af ​​testene i afhængige metoder mislykkes, springer den testen over.

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 = sand: Vi kan indstille attributterne på en testmetode til sandt, og dette vil tvinge testen til at blive udført, selvom nogle af testene i gruppen afhænger af mislykkedes.

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 giver beskrivelsen af ​​metoden. Generelt indeholder den en oversigt over en linje.

Eksempel:

@Test(description = “Regression Test Summary”)

# 8) aktiveret : Denne attribut hjælper med at specificere, om vi vil køre / udføre den bestemte testmetode i den aktuelle suite / klasse eller ej. Nogle gange ønsker vi ikke at køre et par tests på grund af nogle grunde, da kravet / funktionen ofte ændres, og vi vil ikke forstyrre den aktuelle kørsel for den pågældende funktion.

I disse tilfælde kan vi simpelthen ignorere / deaktivere den pågældende test ved at indstille denne funktion som @Test (aktiveret = falsk).

Eksempel:

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

# 9) forventede undtagelser : Denne attribut viser listen over undtagelser, som testmetoden vil kaste i løbetiden. Hvis der ikke kastes nogen undtagelser eller andre undtagelser for metoden, markeres testen som en fiasko.

Eksempel:

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

# 10) grupper : Denne attribut bruges til at specificere de grupper, som testmetoden tilhører.

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

# 11) prioritet : Dette hjælper med at prioritere testmetoderne, mens standardprioriteten starter med 0, og testene udføres i stigende rækkefø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 resultaterne pr. Prioritet, selvom der ikke blev tildelt noget nummer til den første test, tog det sin prioritet som standard 0 og udførelsen blev udført i stigende rækkefølge.

Bestået: launchApp
Bestået: loginApp
Bestået: checkTrans

# 12) timeout : Denne attribut hjælper med at specificere en timeout-værdi til testen (normalt brugt som millisekunder). Hvis testen tager mere end den angivne timeout-værdi, markeres testen som fejl. Vi kan bruge denne timeout til at udføre en præstationstest for at sikre, at metoden vender tilbage inden for en rimelig tid.

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

# 13) invocationCount : Denne attribut hjælper med at bestemme antallet af gange, en testmetode skal påberåbes.

@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();

Produktion:

Sidetitel er Google
Sidetitel er Google
Sidetitel er Google
Sidetitel er Google
Sidetitel er Google

# 14) invocationTimeOut: Dette er den maksimale tid (antal millisekunder), som denne test skal tage for alle indkaldelsestællinger. Denne metode skal bruges sammen med indkaldelsesmetoden, ellers ignoreres den.

Eksempel:

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

Ovenstående eksempel viser, at denne test tager i alt 4 sekunder at udføre, og hver gang testen påkaldes / køres, vil det tage 1 sekund at udføre.

# 15) @DataProvider : Denne metode hjælper med at levere data til en testmetode. Først skal vi erklære en metode, der er kommenteret af @DataProvider, og derefter bruge denne metode i den krævede testmetode ved hjælp af attributten 'DataProvider' i @Test-kommentaren.

En dataudbyder returnerer et array af objekter, især et todimensionalt objekt array () (). Den første matrix repræsenterer et datasæt, og den anden matrix indeholder parametrene.

@DataProvider (name = “Test”) - Her repræsenterer navnet dataudbyderens navn. Hvis navnet ikke er angivet, indstilles DataProvider-navnet automatisk til metodens navn.

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) @Fabrik : Dette bruges til at angive en metode som fabrik til levering af objekter, der skal bruges af TestNG til dets testklasser. Ved at bruge @Factory kan vi oprette dynamiske tests i løbetid, og det skal returnere et array-objekt.

Eksempel:

Lad os tage et eksempel for at forstå det bedre. Vi opretter 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; } }

Produktion : Google blev lanceret med succes

Gmail logget ind med succes

Forskellen mellem @Factory og @DataProvider-kommentarer

Der er en grundlæggende forskel mellem begge kommentarerne. Der er en masse forvirring med hensyn til disse to kommentarer, som hvor man skal bruge disse og hvorfor?

Lad os finde svarene.

@DataProvider: Denne kommentar vil parametrere den bestemte testmetode og udføre testen i et specifikt nr. gange baseret på data leveret af denne metode.

For eksempel, hvis der er to parametre, udføres testmetoden to gange. For eksempel, hvis vi ønsker at logge ind på et websted med forskellige sæt brugernavne og adgangskoder hver gang, så er dette nyttigt, da vi skal angive de parametre, der skal testes.

@Fabrik : Dette udfører alle de testmetoder, der findes i testklassefilen, mens du bruger en separat forekomst af denne klasse. Dette er nyttigt, hvis vi vil køre testklassen et antal gange.

For eksempel , hvis vi er nødt til at teste loginfunktionen på et hvilket som helst program eller websted, og da vi skal køre denne test flere gange, er det bedre at bruge @Factory, hvor vi kan oprette flere forekomster af test og køre testene.

Lad os se på disse eksempler for at kende forskellen.

@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); }

Bemærk : I ovenstående program har vi leveret to data, og programmets resultat vil være:

Navne er: Mihir 145632
Navne er: Kumar 28242

Dette viser, at hvis vi øger antallet af data i meddelelsesmetoden, vil udskrivningsmetoden udføre det samme antal gange.

@Fabrikseksempel :

TestNG Factory er meget nyttig, når vi skal køre flere testklasser ved hjælp af en enkelt testklasse.

Lad os se et eksempel.

Til dette er vi nødt til at oprette to testklasser med få testmetoder inde i 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'); } }

Nu er vi nødt til at definere @Factory-metoden, som returnerer et objektarray af de ovenfor definerede klasser.

Fabriksprogram:

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; } }

Produktion:

Test1 testmetode
Test2 testmetode
PASSED: test1
PASSED: test2

TestNG-lyttere med typer

Enkelt sagt lyttere lytter til begivenheden defineret i Selenium-scriptet og opfører sig i overensstemmelse med det. Hovedformålet er at oprette logfiler og tilpasse TestNG-rapporterne.

Der er mange typer lyttere tilgængelige i TestNG.

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

Men når det kommer til test, bruger vi kun nogle få af dem som beskrevet nedenfor:

# 1) ISuiteListener

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

Når vi implementerer denne lytter, vil det garantere, at slutbrugeren påberåber sig metoderne onStart () og onFinish () før og efter at have kørt en TestNG-suite.

Metodedetaljer:

ugyldigt onStart (ISuite-suite) : Denne metode påberåbes, før Suite Runner starter.

ugyldigt onFinish (ISuite-suite) : Denne metode påberåbes, når Suite Runner har kørt alle testpakkerne.

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 lytter fungerer ligesom ISuiteListener. Den eneste forskel er dog, at det foretager opkaldet før og efter testen og ikke Suite. Det er en lytter til testkørsel, og denne lytter har syv metoder i sig.

(i) onStart () :Denne metode påberåbes, efter at testklassen er instantieret, og før nogen konfigurationsmetode kaldes.

Eksempel:

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

(ii) onFinish () :Denne metode påberåbes, når alle testene er kørt, og alle konfigurationsmetoder kaldes.

Eksempel:

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

(iii) onTestStart () :Denne metode påberåbes hver gang før en test påberåbes. ITestResult er kun delvist udfyldt med referencer til klasse, metode, start millis og status.

Metode: ugyldigt onTestStart (ITestResult-resultat)

Eksempel:

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

(iv) onTestSuccess () :Denne metode påberåbes 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 metode påberåbes 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 metode påberåbes hver gang en test springes over.

Metode: ugyldigt onTestSkipped (ITestResult-resultat)

Eksempel:

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

(vii) onTestFailedButWithinSuccessPercentage :Denne metode påberåbes hver gang en metode mislykkes, men er blevet kommenteret med succesprocent, og fejlen holder den inden for succesprocenten.

Metode: ugyldig onTestFailedButWithinSuccessPercentage (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, der overvåger begyndelsen og slutningen af ​​en TestNG-kørsel. Det har to metoder, dvs. onExecutionStart () og onExecutionFinish () .

onExecutionStart () -metoden kaldes, før TestNG begynder at køre suiterne, og metoden onExecutionFinish () kaldes, efter at TestNG er udført med køringen af ​​alle testsuiterne.

Metode:

ugyldigt onExecutionStart ()

ugyldigt onExecutionFinish ()

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, der påberåbes før og efter at en metode påberåbes af TestNG. Denne lytter kaldes kun til konfigurationer og testmetoder. Det har kun to metoder i det, dvs. efterInvocation og beforeInvocation.

  1. før indkaldelse: Påkald før hver metode.
  2. efterInvokation: Påkald efter hver metode.

Metode:

ugyldig førInvokation (IInvokedMethod-metode, ITestResult testResult)

ugyldig efterInvocation (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 klasse bruges til at ændre listen over testmetoder, som TestNG skal køre. Ved at bruge denne metode kan vi omorganisere listen over testmetoder.

Det gælder kun for de metoder, der ikke er afhængige, og de metoder, der ikke afhænger af andre testmetoder, videregives i parametre. Denne grænseflade returnerer en liste over testmetoder, der skal køres, men på en anden sorteret måde.

Metode:

når regressionstest skal udføres

java.util.List intercept (java.util.List metoder, ITestContext kontekst)

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) IR-rapportør

Dette implementeres af klienterne for at generere en rapport. Denne metode påberåbes, når hele pakken er kørt, og parametrene giver alle de testresultater, der skete under løbet.

Metode:

ugyldigt 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(); }

Konklusion

I denne artikel har vi set, hvordan TestNG-kommentarer kan være nyttige til at gøre vores programlogik lettere. Kommentarer bruges efter behov.

Du kan videregive parametrene til kommentarerne og også udføre datadrevet test. Du kan køre testsagerne i grupper og spare tid. Med lyttere kan du endda generere rapporterne. Synes du ikke dette er vidunderligt?

TestNG.xml vil blive forklaret detaljeret i vores kommende tutorial. Denne XML-fil er rygraden i TestNG-rammen, og den vil hjælpe os med at udføre vores testsager.

=> Tjek den perfekte TestNG-træningsvejledning her.

Anbefalet læsning

^