JUnit ErrorCollector @Regel med eksempel

I et normalt scenario, når du identifiserer en feil under testkjøring, stopper du testen, fikser feilen og kjører testen på nytt.

Men JUnit har en litt annen tilnærming. Med JUnit feilinnsamleren, kan du fortsatt fortsette med testkjøringen selv etter at et problem er funnet eller testen mislykkes. Feilinnsamleren samler alle feilobjekter og rapporterer dem bare én gang, etter at testkjøringen er over.

Hvorfor bruke Error Collector?

Når du skriver et testskript, vil du kjøre alle testene selv om en kodelinje feiler på grunn av nettverksfeil, påstandsfeil eller annen årsak. I den situasjonen kan du fortsatt fortsette å kjøre testskriptet ved hjelp av en spesialfunksjon levert av JUnit kjent som "feilsamler".

For dette, JUnit bruker @Regelmerknad, som brukes til å opprette et objekt for feilinnsamleren. Når objektet for feilinnsamleren er opprettet, kan du enkelt legge til alle feilene i objektet ved hjelp av metoden addError (kastbar feil)Som du vet, Kastbar er superklassen til Unntak og Feil klasser i JavaNår du legger til feil på denne måten, vil disse feilene bli logget i JUnit testresultat.

Fordelen med å legge til alle feil i en feilsamler er at du kan bekrefte alle feilene samtidig. Hvis skriptet feiler midtveis, fortsetter kjøringen til slutten av testmetoden.

MerknaderVed bruk av en enkel assert- eller en try/catch-blokk vil det ikke være mulig å bruke error collector-metoden.

Eksempelkode

For å forstå mer om Error Collector, se kodeeksemplet nedenfor, som demonstrerer hvordan du oppretter et Error Collector-objekt og legger til alle feilene i det objektet. track problemet:

package guru99.junit;		

import org.junit.Rule;		
import org.junit.Test;		
import org.junit.rules.ErrorCollector;		

public class ErrorCollectorExample {				
    @Rule		
    public ErrorCollector collector = new ErrorCollector();							

    @Test		
    public void example() {					
    collector.addError(new Throwable("There is an error in first line"));							
    collector.addError(new Throwable("There is an error in second line"));							
    collector.checkThat(getResults(),			
                not(containsString("here is an error")));			
    // all lines of code will execute and at the end a combined failure will		
    be logged in.		
    }		
}	

OBS: dette er et illustrerende eksempeltract, ikke en kompilerbar fil. Den etterfølgende kommentaren brytes til en andre linje uten en innledende //, og getResults() pluss Hamcrest-matcherne vises ikke. Den komplette kjørbare versjonen følger under Eksempel ved bruk av ErrorCollector.

Hva er @Rule i JUnit?

JUnit gir en spesiell type håndtering av tester, Testsak eller testpakke ved å bruke @RegelmerknadVed å bruke @Rule kan du enkelt legge til eller omdefinere testens oppførsel.

Det finnes flere innebygde regler gitt av JUnit API som en tester kan bruke, og du kan også skrive din egen regel. Et regelfelt må være offentlig, ikke-statisk og av en type som implementerer TestRule.

Se kodelinjen nedenfor, som viser hvordan du bruker @Rule-annotasjonen sammen med Error Collector:

@Rule				
public ErrorCollector collector= new ErrorCollector();

JUnit 5-notat: Jupiter erstattet regler med Extension API, så @Rule og ErrorCollector finnes ikke i org.junit.jupiter. De nærmeste ekvivalentene er Assertions.assertAll() og AssertJ SoftAssertions. JUnit 4-koden som vises her kjører fortsatt gjennom den gamle motoren. Se JUnit merknader veiledning for hele kartetping.

Eksempel ved bruk av ErrorCollector

For å forstå feilinnsamleren, la oss lage en klasse og en regel for å samle alle feilene. Du legger til alle feilene ved hjelp av addError(throwable) her.

Se koden nedenfor, som ganske enkelt oppretter en regel som ikke er noe annet enn et «Error Collector-objekt». Den brukes videre til å legge til alle feilene for å rapportere problemet på slutten:

ErrorCollectorExample.java

package guru99.junit;		

import org.junit.Assert;		
import org.junit.Rule;		
import org.junit.Test;		
import org.junit.rules.ErrorCollector;		

public class ErrorCollectorExample {				
    @Rule		
    public ErrorCollector collector = new ErrorCollector();							

    @Test		
    public void example() {					
    collector.addError(new Throwable("There is an error in first line"));							
    collector.addError(new Throwable("There is an error in second line"));							

        System.out.println("Hello");					
        try {			
            Assert.assertTrue("A " == "B");					
        } catch (Throwable t) {					
            collector.addError(t);					
        }		
        System.out.println("World!!!!");					
    }		
}		

TestRunner.java

La oss legge til testklassen ovenfor i en testkjører og kjøre den for å samle alle feilene. Se koden nedenfor:

package guru99.junit;		

import org.junit.runner.JUnitCore;		
import org.junit.runner.Result;		
import org.junit.runner.notification.Failure;		

public class TestRunner {				
			public static void main(String[] args) {									
      Result result = JUnitCore.runClasses(ErrorCollectorExample.class);					
			for (Failure failure : result.getFailures()) {							
         System.out.println(failure.toString());					
      }		
      System.out.println("Result=="+result.wasSuccessful());							
   }		
}      

Utgang:

Se feilen trace, som tracalle feilene på ett sted. JUnit visningen teller én kjøring, men rapporterer to feil og én feil, hver med sitt eget linjenummer:

Fordeler med JUnit ErrorCollector

Du kan bruke en JUnit påstand for funksjonell eller GUI-validering, for eksempel:

1. assertEquals(String message, Object expected, Object actual), som sammenligner at to objekter er like.
2. På samme måte hevder assertTrue (boolsk tilstand) at en betingelse er sann.

Ved å bruke påstander blir valideringstesting enkelt. Men et stort problem er at testkjøringen vil stoppe selv om en enkelt påstand mislykkes.

Testkontinuitet og gjenopprettingshåndtering er avgjørende for suksess med testautomatisering, og det er viktigst på lang sikt. Selenium flyter der det er dyrt å starte en nettleser på nytt etter hver mislykkede sjekk. Error Collector er den beste måten å håndtere slike scenarier på.

Spørsmål og svar