streamalism.org

1. Oversikt

La oss forestille oss at vi har en test for noen kode som avhenger av operativsystemet, og som bare skal kjøre hvis testmaskinen vår kjører på Linux. Hvis den kjører på et annet operativsystem, vil vi at testen ikke skal mislykkes, men at den ignoreres ved kjøretid.

En første tilnærming kan være å bruke et par hvis uttalelser for å se etter denne tilstanden ved hjelp av System klasseegenskaper. Dette fungerer selvfølgelig, men JUnit har en renere og mer elegant metode.

I denne korte opplæringen skal vi se på hvordan vi kan kjøre eller ignorere tester i JUnit 4 med Anta klasse.

2. Den Anta Klasse

Denne klassen gir et sett med metoder for å støtte betinget testutførelse basert på visse forhold. Testen vår kjører bare hvis alle disse vilkårene er oppfylt. Hvis ikke, JUnit vil bare hoppe over kjøringen og merke den som bestått i testrapporten. Sistnevnte er hovedforskjellen med Påstå klasse, der en sviktende tilstand fører til at testen slutter som mislykkes.

En viktig ting å merke seg er at oppførselen vi beskrev for Anta klasse er eksklusiv for standard JUnit-løper. For tilpassede løpere kan ting være annerledes.

Til slutt, på samme måte som med Påstå, vi kan kalle Anta metoder enten i @Før eller @BeforeClass merkede metoder eller innenfor @Test selve metoden.

La oss nå gå gjennom de mest nyttige metodene for Anta klasse ved å vise noen eksempler. La oss anta for alle de følgende eksemplene getOsName () returnerer Linux.

2.1. Ved hjelp av anta at

De anta at() metoden sjekker at staten - i dette tilfellet, getOsName () - oppfyller vilkårene for matcheren som er bestått i:

@Test offentlig ugyldig nårAssumeThatAndOSIsLinux_thenRunTest () {antar at (getOsName (), er ("Linux")); assertEquals ("run", "RUN" .toLowerCase ()); }

I dette eksemplet, vi sjekket om getOsName () tilsvarer Linux. Som getOsName () returnerer Linux, blir testen kjørt. Merk, vi bruker Hamcrest matcher-metoden er (T) som matcheren her.

2.2. Ved hjelp av antar sant

På samme måte kan vi bruke antar sant () metode for å spesifisere et boolsk uttrykk som må evalueres til ekte for at testen skal kjøre. Hvis det evalueres til falsk, blir testen ignorert:

private boolske isExpectedOS (String osName) {return "Linux" .equals (osName); } @Test offentlig ugyldig nårAssumeTrueAndOSIsLinux_thenRunTest () {antarTrue (isExpectedOS (getOsName ())); assertEquals ("run", "RUN" .toLowerCase ()); } 

I dette tilfellet, isExpectedOs () returnerer ekte. Derfor, devilkårene for at testen skal kjøre er oppfylt, og testen vil bli kjørt.

2.3. Ved hjelp av antar falske

Til slutt kan vi bruke det motsatte antar Falske () metode for å spesifisere et boolsk uttrykk som må evalueres til falsk for at testen skal kjøre. Hvis det evalueres til ekte, blir testen ignorert:

@Test offentlig ugyldig nårAssumeFalseAndOSIsLinux_thenIgnore () {antarFalse (isExpectedOS (getOsName ())); assertEquals ("run", "RUN" .toLowerCase ()); }

I dette tilfellet, som isExpectedOs () også returnerer ekte,devilkårene for at testen skal kjøre ikke er oppfylt, og testen vil bli ignorert.

2.4. Ved hjelp av antarIkkeNull

Når vi vil ignorere en test hvis noe uttrykk er null, vi kan bruke antarNotNull () metode:

@Test offentlig ugyldig nårAssumeNotNullAndNotNullOSVersion_thenRun () {antarNotNull (getOsName ()); assertEquals ("run", "RUN" .toLowerCase ()); }

Som getOsName () returnerer en verdi som ikke er null, vilkåret for at testen skal kjøres er oppfylt og testen vil kjøre.

2.5. Ved hjelp av antar ingen unntak

Til slutt kan det være lurt å ignorere en test hvis et unntak blir kastet. Vi kan bruke antar ingen unntak () for dette formålet:

@Test offentlig ugyldig nårAssumeNoExceptionAndExceptionThrown_thenIgnore () {assertEquals ("alt ok", "ALT OK" .toLowerCase ()); Streng t = null; prøv {t.charAt (0); } fange (NullPointerException npe) {antarNoException (npe); } assertEquals ("run", "RUN" .toLowerCase ()); }

I dette eksemplet, som t er null,en NullPointerException unntak kastes derfor de vilkårene for at testen skal kjøre ikke er oppfylt, og testen vil bli ignorert.

3. Hvor skal vi plassere antarXXX Anrop?

Det er viktig å merke seg det oppførselen til antarXXX metoder avhenger av hvor vi legger dem i testene våre.

La oss modifisere litt anta at eksempel så assertEquals () samtalen går først. La oss også lage assertEquals () mislykkes:

@Test offentlig ugyldig nårAssumeFalseAndOSIsLinux_thenIgnore () {assertEquals ("run", "RUN"); anta Falsk (isExpectedOS (getOsName ())); } 

Når vi kjører dette eksemplet, har vi:

org.junit.ComparisonFailure: Expected: run Actual: RUN

I dette tilfellet, testen vår blir ikke ignorert fordi den mislyktes før vi nådde anta at() anrop. Det samme skjer med alle antarXXX metoder. Så vi må sørg for at vi setter dem på rett sted inne i testmetoden.

4. Konklusjon

I denne korte opplæringen har vi sett hvordan vi betinget kan bestemme om en test skal kjøres ved hjelp av Anta klasse i JUnit 4. I tilfelle vi bruker JUnit 5, er den også tilgjengelig i versjon 5.4 eller nyere.

Som alltid kan kildekoden til eksemplene vi har vært igjennom finnes på GitHub.