streamalism.org

1. Oversigt

Jukito er den kombinerede effekt af JUnit, Guice og Mockito - bruges til at forenkle testning af flere implementeringer af den samme grænseflade.

I denne artikel vil vi se, hvordan forfattere formåede at kombinere disse tre biblioteker for at hjælpe os med at reducere en masse kedelpladekode, hvilket gør vores test fleksible og lette.

2. Opsætning

Først tilføjer vi følgende afhængighed af vores projekt:

 org.jukito jukito 1.5 test 

Vi kan finde den nyeste version på Maven Central.

3. Forskellige implementeringer af et interface

For at begynde at forstå styrken ved Jukito skal vi definere en simpel Lommeregner interface til en Tilføje metode:

offentlig grænseflade-lommeregner {offentlig dobbelt tilføj (dobbelt a, dobbelt b); }

Og vi vil implementere følgende grænseflade:

offentlig klasse SimpleCalculator implementerer Lommeregner {@Override offentlig dobbelt tilføj (dobbelt a, dobbelt b) {returner + + b; }}

Vi har også brug for en anden implementering:

offentlig klasse ScientificCalculator udvider SimpleCalculator {}

Lad os nu bruge Jukito til at teste begge vores implementeringer:

@RunWith (JukitoRunner.class) public class CalculatorTest {public static class Module udvider JukitoModule {@Override beskyttet ugyldigt configureTest () {bindMany (Calculator.class, SimpleCalculator.class, ScientificCalculator.class); }} @Test offentlig ugyldighed givenTwoNumbers_WhenAdd_ThenSumBoth (@All Calculator calc) {dobbelt resultat = calc.add (1, 1); assertEquals (2, resultat, .1); }}

I dette eksempel kan vi se a JukitoModule, der kabler i alle specificerede implementeringer.

Det @Alle annotation tager alle bindinger af samme interface lavet af JukitoModule og kører testen med alle de forskellige implementeringer injiceret ved kørsel.

Hvis vi kører tests, kan vi se, at der faktisk køres to tests i stedet for en:

Testkørsel: 2, Fejl: 0, Fejl: 0, Springet over: 0

4. Det kartesiske produkt

Lad os nu tilføje en simpel indlejret klasse til forskellige kombinationer af tests til vores Tilføje metode:

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

Dette vil udvide antallet af tests, vi kan køre, men først skal vi tilføje yderligere bindinger i vores configureTest metode:

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

Og endelig tilføjer vi endnu en test til vores suite:

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

Nu det @Alle annotering vil producere det kartesiske produkt af de forskellige kombinationer mellem de forskellige implementeringer af Lommeregner interface og AdditionTest tilfælde.

Vi kan se på det øgede antal tests, det nu producerer:

Testkørsel: 8, Fejl: 0, Fejl: 0, Springet over: 0

Vi skal huske, at antallet af testudførelser stiger drastisk for kartesiske produkter.

Udførelsestiden for alle tests vokser lineært med antallet af henrettelser. i: e .: en testmetode med tre parametre med en @Alle annotering og fire bindinger pr. parameter udføres 4 x 4 x 4 = 64 gange.

At have fem bindinger til den samme testmetode vil føre til 5 x 5 x 5 = 125 henrettelser.

5. Gruppering efter navne

Den sidste funktion, vi diskuterer, er grupperingen efter navn:

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

Her tilføjede vi nogle navngivne forekomster af heltalsklassen til vores configureTest metode for at vise, hvad der kan gøres med disse grupper.

Lad os nu tilføje nogle flere tests:

@Test offentlig ugyldighed givenEvenNumbers_whenPrint_thenOutput (@All ("lige") Heltal i) {System.out.println ("lige" + i); } @Test offentlig ugyldighed givenOddNumbers_whenPrint_thenOutput (@All ("ulige") Heltal i) {System.out.println ("ulige" + i); }

Ovenstående eksempel udskriver de seks strenge "lige 2", "lige 4", "lige 6", "ulige 1", "ulige 3", "ulige 5".

Husk at rækkefølgen af ​​disse ikke er garanteret ved kørsel.

6. Konklusion

I denne hurtige vejledning kiggede vi på, hvordan Jukito tillader brug af en hel testpakke ved at levere lige nok kombinationer af testcases.

Det komplette eksempel kan findes på GitHub.