Menu

TestNG-annotaties en luisteraars

testng annotations listeners

Probeer Ons Instrument Voor Het Oplossen Van Problemen

In deze zelfstudie worden de verschillende soorten TestNG-annotaties en luisteraars uitgelegd. U zult ook leren hoe u de TestNG-annotaties en luisteraars kunt gebruiken met voorbeelden:

Hier zullen we een standaard TestNG-programma uitvoeren met TestNG-annotaties en ook de rol van TestNG-luisteraars bekijken en zien hoe ze bij het testen kunnen worden gebruikt.

​ Lees de Easy TestNG-trainingsreeks door.

TestNG-annotaties en luisteraars

Wat je leert:

Wat zijn TestNG-annotaties?

Dit zijn de programma- of bedrijfslogica die worden gebruikt bij het beheersen van de stroom van methoden. Ze spelen een zeer belangrijke rol in TestNG. Deze annotaties verschillen per project volgens de vereisten. De stroom van annotaties blijft in elk programma hetzelfde ondanks de verschillende vereisten.

Er zijn verschillende soorten TestNG-annotaties die TestNG gemakkelijker en beter maken dan JUnit. Elk van deze annotaties wordt uitgevoerd op een specifiek evenement in de TestNG.

Typen annotaties in TestNG

Hieronder vindt u de lijsten met annotaties en hun attributen die in TestNG worden gebruikt. Laten we ze en hun gebruik in detail bekijken.

Voordat

  • @BeforeSuite: Deze methode wordt uitgevoerd voordat alle tests in de suite worden uitgevoerd.
  • @BeforeTest: Deze methode wordt uitgevoerd voordat elke testsectie in de suite wordt gedeclareerd.
  • @Voor klas: Deze methode wordt uitgevoerd vóór de eerste testmethode in de huidige klasse.
  • @BeforeMethod: Deze methode wordt voor elke testmethode uitgevoerd.
  • @BeforeGroups: Deze methode wordt uitgevoerd voordat een testmethode van de opgegeven groep wordt genoemd.
  • @Test : Markeert een klasse of methode als onderdeel van de test. Of we kunnen zeggen dat het een methode maakt als testmethode.

Na

  • @AfterSuite: Deze methode wordt uitgevoerd nadat alle tests in de suite zijn uitgevoerd.
  • @AfterTest: Deze methode wordt uitgevoerd nadat elke testsectie in de suite is gedeclareerd.
  • @Na de les: Deze methode wordt uitgevoerd na de laatste testmethode van de klasse.
  • @AfterMethod: Deze methode wordt uitgevoerd nadat elke testmethode is uitgevoerd.
  • @AfterGroups: Deze methode wordt uitgevoerd nadat de laatste testmethode van de opgegeven groep is uitgevoerd.

Werkstroom van annotaties

Wanneer we het TestNG.xml-bestand uitvoeren, worden de TestNG-annotaties in de volgende volgorde uitgevoerd:

Before Suite-> Before Test-> Before Class-> Before Method-> @Test -> After Method-> After Class-> After Test-> After Suite

​

@Test heeft veel andere attributen die ons helpen onze testcases effectiever uit te voeren.

Hieronder staan ​​de soorten attributen en hun beschrijvingen met voorbeelden.

# 1) alwaysRun: Indien ingesteld op true, wordt deze methode uitgevoerd, zelfs als deze afhankelijk is van een methode die is mislukt.

Voorbeeld: Test (alwaysRun = true)

# 2) dataprovider : Dit toont de naam van de gegevensprovider voor deze methode. Het heeft alleen attributen, d.w.z. naam. We kunnen het gebruiken wanneer we onze software testen met meerdere sets gegevens tijdens invoertijd of runtime. Dit wordt ook wel datagedreven testen genoemd. Met dit kenmerk kunnen we datagedreven testen uitvoeren.

Voorbeeld: @dataProvider (name = ”TestData”)

# 3) dataProviderClass : Met dit kenmerk kunt u de gegevensprovidersklasse specificeren die de gegevensprovider bevat die de @Test-methode zal gebruiken.

Voorbeeld: @Test (dataProvider = 'Client Data Test', dataProviderClass = ClientDetailsTest.class)

# 4) afhankelijkOnGroups : Dit attribuut is afhankelijk van de lijst met groepen, d.w.z. de testmethode start pas met uitvoeren nadat de afhankelijke groepen zijn uitgevoerd.

Opmerking : Als een van de tests in de groepen die afhankelijk zijn van mislukt, wordt die test overgeslagen.

Hieronder is het voorbeeld:

​

# 5) afhankelijkOnMethods : Deze annotatie is afhankelijk van de lijst met methoden. Dit betekent dat de testmethode pas wordt uitgevoerd nadat de afhankelijke methoden zijn uitgevoerd.

Opmerking : Als een van de tests in afhankelijke methoden mislukt, wordt die test overgeslagen.

Voorbeeld:

​

# 6) alwaysRun = true: We kunnen de attributen van een testmethode op true zetten, en dit zal de test dwingen om te worden uitgevoerd, zelfs als sommige tests in de groep afhankelijk zijn van mislukken.

Bijvoorbeeld:

​

# 7) beschrijving : Dit geeft de beschrijving van de methode. Over het algemeen bevat het een samenvatting van één regel.

Voorbeeld:

​

# 8) ingeschakeld : Dit attribuut helpt bij het specificeren of we de specifieke testmethode in de huidige suite / klasse willen uitvoeren / uitvoeren of niet. Soms willen we een paar tests niet uitvoeren vanwege een aantal redenen, zoals de vereiste / functie vaak verandert en we de huidige run voor die specifieke functie niet willen verstoren.

In die gevallen kunnen we die specifieke test eenvoudigweg negeren / uitschakelen door deze functie in te stellen als @Test (enabled = false).

Voorbeeld:

​

# 9) verwacht Uitzonderingen : Dit attribuut toont de lijst met uitzonderingen die de testmethode in de runtime zal veroorzaken. Als er geen uitzonderingen of een andere uitzondering wordt gegenereerd voor de methode, wordt de test gemarkeerd als mislukt.

Voorbeeld:

​

# 10) groepen : Dit attribuut wordt gebruikt om de groepen te specificeren waartoe de testmethode behoort.

​

# 11) prioriteit : Dit helpt bij het prioriteren van de testmethoden, terwijl de standaardprioriteit begint met 0 en de tests in oplopende volgorde worden uitgevoerd.

Voorbeeld:

​

Resultaten: Hieronder staan ​​de resultaten per prioriteit, ook al was er geen nummer toegewezen aan de eerste test, deze kreeg standaard de prioriteit 0 en de uitvoering werd in oplopende volgorde uitgevoerd.

Geslaagd: launchApp
Geslaagd: loginApp
Geslaagd: checkTrans

# 12) time-out : Dit kenmerk helpt bij het specificeren van een time-outwaarde voor de test (meestal gebruikt als milliseconden). Als de test langer duurt dan de opgegeven time-outwaarde, wordt de test gemarkeerd als mislukt. We kunnen deze time-out gebruiken om een ​​prestatietest uit te voeren, om er zeker van te zijn dat de methode binnen een redelijke tijd terugkeert.

​

# 13) invocationCount : Dit attribuut helpt bij het bepalen van het aantal keren dat een testmethode moet worden aangeroepen.

​

Uitgang:

Paginatitel is Google
Paginatitel is Google
Paginatitel is Google
Paginatitel is Google
Paginatitel is Google

# 14) invocationTimeOut: Dit is de maximale tijd (aantal milliseconden) die deze test zou moeten duren voor alle aanroep-tellingen. Deze methode moet samen met de aanroep-telmethode worden gebruikt, anders wordt deze genegeerd.

Voorbeeld:

​

Het bovenstaande voorbeeld laat zien dat deze test in totaal 4 seconden nodig heeft om uit te voeren en elke keer dat de test wordt aangeroepen / uitgevoerd, duurt het 1 seconde om uit te voeren.

# 15) @DataProvider : Deze methode helpt bij het aanleveren van gegevens voor een testmethode. Eerst moeten we een methode declareren die is geannoteerd door @DataProvider en deze methode vervolgens gebruiken in de vereiste testmethode met behulp van het 'DataProvider' -attribuut in de @Test-annotatie.

Een gegevensprovider retourneert een array van objecten, met name een tweedimensionale objectarray () (). De eerste array vertegenwoordigt een dataset en de tweede array bevat de parameters.

@DataProvider (name = 'Test') - Hier vertegenwoordigt de naam de naam van de gegevensprovider. Als de naam niet wordt gegeven, wordt de naam van de dataprovider automatisch ingesteld op de naam van de methode.

Voorbeeld:

​

# 16) @Fabriek : Dit wordt gebruikt om een ​​methode te specificeren als een fabriek voor het leveren van objecten die door TestNG moeten worden gebruikt voor zijn testklassen. Door @Factory te gebruiken, kunnen we dynamische tests tijdens runtime maken en het zou een array-object moeten retourneren.

Voorbeeld:

Laten we een voorbeeld nemen om het beter te begrijpen. We zullen twee klassen maken, namelijk FactorySample.Java en FactoryTest.Java

Fabrieksvoorbeeld.Java

​

FactoryTest.Java

​

Uitvoer : Google is succesvol gelanceerd

Gmail is succesvol ingelogd

Verschil tussen @Factory en @DataProvider-annotaties

Er is een fundamenteel verschil tussen beide annotaties. Er is veel verwarring over deze twee annotaties, zoals waar deze te gebruiken en waarom?

Laten we de antwoorden zoeken.

@Data provider: Deze annotatie zal de specifieke testmethode parametriseren en de test uitvoeren in een specifiek nr. keer op basis van de gegevens die door deze methode worden verstrekt.

Bijvoorbeeld, als er twee parameters zijn, wordt de testmethode twee keer uitgevoerd. Als we bijvoorbeeld willen inloggen op een site met elke keer verschillende sets gebruikersnamen en wachtwoorden, dan is dit handig omdat we de parameters moeten opgeven om te testen.

@Fabriek : Hiermee worden alle testmethoden uitgevoerd die aanwezig zijn in het testklasse-bestand terwijl een afzonderlijk exemplaar van die klasse wordt gebruikt. Dit is handig als we de testklasse een willekeurig aantal keren willen uitvoeren.

Bijvoorbeeld , als we de inlogfunctie van een applicatie of website moeten testen en aangezien we deze test meerdere keren moeten uitvoeren, is het beter om @Factory te gebruiken, waar we meerdere testinstanties kunnen maken en de tests kunnen uitvoeren.

Laten we deze voorbeelden eens bekijken om het verschil te zien.

@DataProvider Voorbeeld ​

​

Opmerking : In het bovenstaande programma hebben we twee gegevens verstrekt en het resultaat van het programma zou zijn:

Namen zijn: Mihir 145632
Namen zijn: Kumar 28242

Dit toont aan dat als we het aantal gegevens in de berichtmethode verhogen, de afdrukmethode hetzelfde aantal keren zal worden uitgevoerd.

@Factory Voorbeeld ​

TestNG Factory is erg handig als we meerdere testklassen moeten draaien met één testklasse.

Laten we een voorbeeld bekijken.

Hiervoor moeten we twee testklassen maken met weinig testmethoden erin.

TestData 1:

​

TestData 2:

​

Nu moeten we de @Factory-methode definiëren die een object-array van de hierboven gedefinieerde klassen retourneert.

Fabrieksprogramma:

​

Uitgang:

Test1 testmethode
Test2 testmethode
GESLAAGD: test1
GESLAAGD: test2

TestNG-luisteraars met typen

In eenvoudige bewoordingen luisteren luisteraars naar de gebeurtenis die is gedefinieerd in het Selenium-script en gedragen zich dienovereenkomstig. Het belangrijkste doel is om logboeken te maken en de TestNG-rapporten aan te passen.

Er zijn veel soorten luisteraars beschikbaar in TestNG.

Bijvoorbeeld , IAnnotationTransformer, IAnnotationTransformer2, IConfigurable, IConfigurationListener, IConfigurationListener2, IExecutionListener, IHookable, IInvokedMethodListener, IInvokedMethodListener2, IMethodInterceptor, IReporter, ISestuite

Als het echter om testen gaat, gebruiken we er maar een paar, zoals hieronder besproken:

#1) ISuiteListener

Dit is een luisteraar voor testsuites. Het bestaat uit twee methoden, d.w.z. onStart () en onFinish () ​

Elke keer dat we deze listener implementeren, garandeert dit dat de eindgebruiker de methoden onStart () en onFinish () zal aanroepen voor en na het uitvoeren van een TestNG-suite.

Methode details:

ongeldig onStart (ISuite suite) : Deze methode wordt aangeroepen voordat de Suite Runner start.

ongeldig onFinish (ISuite suite) : Deze methode wordt aangeroepen nadat de Suite Runner alle testsuites heeft uitgevoerd.

Voorbeeld:

​

# 2) ITestListener

Deze luisteraar werkt net als de ISuiteListener. Het enige verschil is echter dat er voor en na de test wordt gebeld en niet de suite. Het is een listener voor het uitvoeren van tests en deze listener heeft zeven methoden.

(i) onStart () ​Deze methode wordt aangeroepen nadat de testklasse is geïnstantieerd en voordat een configuratiemethode wordt aangeroepen.

Voorbeeld:

​

(ii) onFinish () ​Deze methode wordt aangeroepen nadat alle tests zijn uitgevoerd en alle configuratiemethoden zijn aangeroepen.

Voorbeeld:

​

(iii) onTestStart () ​Deze methode wordt elke keer aangeroepen voordat een test wordt aangeroepen. Het ITestResult is slechts gedeeltelijk gevuld met de verwijzingen naar class, method, start millis en status.

Methode: void onTestStart (ITestResult resultaat)

Voorbeeld:

​

(iv) onTestSuccess () ​Deze methode wordt elke keer aangeroepen wanneer een test slaagt.

Methode: void onTestSuccess (ITestResult resultaat)

Voorbeeld:

​

(v) onTestFailure () ​Deze methode wordt telkens aangeroepen wanneer een test mislukt.

Methode: void onTestFailure (ITestResult resultaat)

Voorbeeld:

​

(vi) onTestSkipped () ​Deze methode wordt elke keer aangeroepen wanneer een test wordt overgeslagen.

Methode: ongeldig onTestSkipped (ITestResult resultaat)

Voorbeeld:

​

(vii) onTestFailedButWithinSuccessPercentage ​Deze methode wordt elke keer aangeroepen wanneer een methode is mislukt, maar is geannoteerd met succespercentage en de mislukking houdt het binnen het succespercentage.

Methode: void onTestFailedButWithinSuccessPercentage (ITestResult resultaat)

Voorbeeld:

​

# 3) IExecutionListener

Het is een luisteraar die het begin en einde van een TestNG-run bewaakt. Het heeft twee methoden, d.w.z. onExecutionStart () en onExecutionFinish () ​

De methode onExecutionStart () wordt aangeroepen voordat de TestNG de suites begint uit te voeren en de methode onExecutionFinish () wordt aangeroepen nadat TestNG klaar is met het uitvoeren van alle testsuites.

Methode:

ongeldig onExecutionStart ()

ongeldig onExecutionFinish ()

Voorbeeld:

​

# 4) IInvokedMethodListener

Het is een luisteraar die wordt aangeroepen voordat en nadat een methode wordt aangeroepen door TestNG. Deze listener wordt alleen aangeroepen voor configuraties en testmethoden. Het heeft slechts twee methoden, namelijk afterInvocation en beforeInvocation.

  1. vóór de uitnodiging: Roep voor elke methode aan.
  2. afterInvocation: Roep na elke methode aan.

Methode:

void beforeInvocation (IInvokedMethod-methode, ITestResult testResult)

void afterInvocation (IInvokedMethod-methode, ITestResult testResult)

Voorbeeld:

​

# 5) IMethodInterceptor

Deze klasse wordt gebruikt om de lijst met testmethoden die TestNG gaat uitvoeren, te wijzigen. Door deze methode te gebruiken, kunnen we de lijst met testmethoden opnieuw ordenen.

Het is alleen van toepassing op methoden die geen afhankelijkheden hebben en methoden die niet afhankelijk zijn van andere testmethoden, worden doorgegeven in parameters. Deze interface retourneert een lijst met testmethoden die moeten worden uitgevoerd, maar op een andere gesorteerde manier.

Methode:

wat is de beste anti-spyware

java.util.List onderscheppen (java.util.List methoden, ITestContext context)

Voorbeeld:

​

# 6) IReporter

Dit wordt door de klanten geïmplementeerd om een ​​rapport te genereren. Deze methode wordt aangeroepen zodra de volledige suite is uitgevoerd en de parameters alle testresultaten geven die tijdens die run zijn opgetreden.

Methode:

void generationReport (java.util.List xmlSuites, java.util.List suites, java.lang.String outputDirectory)

Voorbeeld:

​

Gevolgtrekking

In dit artikel hebben we gezien hoe TestNG-annotaties nuttig kunnen zijn om onze Programmalogica gemakkelijker te maken. Annotaties worden indien nodig gebruikt.

U kunt de parameters doorgeven aan de annotaties en ook gegevensgestuurde tests uitvoeren. U kunt de testcases in groepen uitvoeren en tijd besparen. Met luisteraars kunt u zelfs de rapporten genereren. Vind je dit niet geweldig?

TestNG.xml zal in detail worden uitgelegd in onze aanstaande tutorial. Dit XML-bestand vormt de ruggengraat van het TestNG-framework en het zal ons helpen bij het uitvoeren van onze testcases.

​ Bekijk hier de perfecte TestNG-trainingsgids.

Aanbevolen literatuur

^