streamalism.org

1. Oversikt

Jukito er den kombinerte kraften til JUnit, Guice og Mockito - brukt til å forenkle testing av flere implementeringer av samme grensesnitt.

I denne artikkelen skal vi se hvordan forfattere klarte å kombinere disse tre bibliotekene for å hjelpe oss med å redusere mye kjelekode, noe som gjør testene våre fleksible og enkle.

2. Oppsett

Først vil vi legge til følgende avhengighet i prosjektet vårt:

 org.jukito jukito 1.5 test 

Vi finner den nyeste versjonen på Maven Central.

3. Ulike implementeringer av et grensesnitt

For å begynne å forstå kraften til Jukito, skal vi definere en enkel Kalkulator grensesnitt med en Legge til metode:

offentlig grensesnitt Kalkulator {offentlig dobbelt legg til (dobbelt a, dobbelt b); }

Og vi skal implementere følgende grensesnitt:

offentlig klasse SimpleCalculator implementerer kalkulator {@Override offentlig dobbel add (dobbel a, dobbel b) {return a + b; }}

Vi trenger også en ny implementering:

offentlig klasse ScientificCalculator utvider SimpleCalculator {}

La oss nå bruke Jukito til å teste begge implementeringene våre:

@RunWith (JukitoRunner.class) public class CalculatorTest {public static class Module utvider JukitoModule {@Override-beskyttet ugyldig configureTest () {bindMany (Calculator.class, SimpleCalculator.class, ScientificCalculator.class); }} @Test offentlig ugyldighet givenTwoNumbers_WhenAdd_ThenSumBoth (@All Calculator calc) {doble resultat = calc.add (1, 1); assertEquals (2, resultat, .1); }}

I dette eksemplet kan vi se a JukitoModule, som kabler i alle spesifiserte implementeringer.

De @Alle kommentar tar alle bindinger av samme grensesnitt laget av JukitoModule og kjører testen med alle de forskjellige implementeringene injisert ved kjøretid.

Hvis vi kjører tester, kan vi se at det faktisk kjøres to tester i stedet for en:

Testkjøring: 2, Feil: 0, Feil: 0, Hoppet over: 0

4. Det kartesiske produktet

La oss nå legge til en enkel nestet klasse for forskjellige kombinasjoner av tester for vår Legge til metode:

offentlig statisk klasse AdditionTest {int a; int b; int forventet; // standardkonstruktører / getters}

Dette vil utvide antall tester vi kan kjøre, men først må vi legge til flere bindinger i vår configureTest metode:

bindManyInstances (AdditionTest.class, new AdditionTest (1, 1, 2), new AdditionTest (10, 10, 20), new AdditionTest (18, 24, 42));

Og til slutt legger vi til en ny test i suiten vår:

@Test offentlig ugyldighet givenTwoNumbers_WhenAdd_ThenSumBoth (@All Calculator calc, @All AdditionTest addTest) {double result = calc.add (addTest.a, addTest.b); assertEquals (addTest.expected, result, .1); }

Nå de @Alle merknader kommer til å produsere det kartesiske produktet av de forskjellige kombinasjonene mellom de forskjellige implementeringene av Kalkulator grensesnitt og AdditionTest tilfeller.

Vi kan se på det økte antallet tester det nå produserer:

Testkjøring: 8, Feil: 0, Feil: 0, Hoppet over: 0

Vi må huske at antall testutførelser øker drastisk for kartesiske produkter.

Gjennomføringstiden for alle testene vil vokse lineært med antall henrettelser. i: e .: en testmetode med tre parametere med en @Alle kommentar og fire bindinger per parameter vil bli utført 4 x 4 x 4 = 64 ganger.

Å ha fem bindinger for den samme testmetoden vil føre til 5 x 5 x 5 = 125 henrettelser.

5. Gruppering etter navn

Den siste funksjonen vi diskuterer er grupperingen etter navn:

bindManyNamedInstances (Integer.class, "even", 2, 4, 6); bindManyNamedInstances (Integer.class, "odd", 1, 3, 5);

Her la vi til noen navngitte forekomster av heltallsklassen til vår configureTest metode for å vise hva som kan gjøres med disse gruppene.

La oss nå legge til noen flere tester:

@Test offentlig ugyldighet gittEvenNumbers_whenPrint_thenOutput (@All ("even") Heltall i) {System.out.println ("even" + i); } @Test offentlig ugyldig gittOddNumbers_whenPrint_thenOutput (@All ("odd") Heltall i) {System.out.println ("odd" + i); }

Ovenstående eksempel vil skrive ut de seks strengene "jevn 2", "jevn 4", "jevn 6", "odde 1", "odde 3", "odde 5".

Husk at rekkefølgen på disse ikke er garantert ved kjøretid.

6. Konklusjon

I denne raske opplæringen tok vi en titt på hvordan Jukito tillater bruk av en hel testpakke, ved å tilby akkurat nok kombinasjoner av testtilfeller.

Hele eksemplet finner du på GitHub.