Java >> Java opplæring >  >> Java

Skrive datadrevne tester for Java-applikasjonen din

Java

JUnit er et ekstremt kraftig testrammeverk som ikke bare gir brukerne en mulighet til å skrive raske og enkle tester, men som også gir brukerne en mulighet til å utvide det og få det til å fungere slik de vil ha det. Mange rammeverk er bygget på toppen av JUnit som gir ulike brukervennlige funksjoner til målgruppen deres.

EasyTest er et slikt rammeverk hvis primære fokus er å bringe datadrevet testfunksjonalitet til JUnit-verdenen.

JUnit har allerede en mekanisme på plass som gir brukerne en slags datadrevet testfølelse. Men det er ikke tilstrekkelig, og det er heller ikke rent. for eksempel kan en bruker bruke @Parameterized Runner til å skrive datadrevne tester, men bruk av Parameterized Runner resulterer i mye unødvendig kode som skal skrives.

EasyTest prøver å løse problemene ved å bygge bro mellom det JUnit allerede har og det som er mest praktisk for brukerne.

I dagens innlegg vil jeg gi en kort oversikt over hva EasyTest er og hvordan det har utviklet seg fra å være en hobby til et fullverdig prosjekt som brukes i mange bedrifter og av mange mennesker.

Kom i gang

For å komme i gang med EasyTest er alt du trenger å gjøre å laste ned JAR-filen. Du kan gjøre det via Maven. Her er lenken til den nyeste easytest-core JAR på Maven.

Når du har lastet ned JAR-filen, er du klar til å skrive din første datadrevne test. Her er en trinnvis veiledning for å komme raskt i gang med EasyTest Core Module.

Trinn 1 :Ha den nyeste EasyTest-avhengigheten i pom-filen din:

<dependency>
<groupId>org.easetech</groupId>
<artifactId>easytest-core</artifactId>
<version>1.3.2</version>
</dependency>

Trinn 2 :Lag en enkel testklasse med testmetode

@RunWith(DataDrivenTestRunner.class)
    @DataLoader(filePaths = { "testExcelData.xls" })
    public class TestExcelDataLoader{
    
      private ItemService itemService = new RealItemService();

    @Test
    public void getExcelTestData(@Param(name="libraryId")
    Float libraryId, @Param(name="itemId")
    Float itemId) {
        System.out.print("Executing getExcelTestData :");
        System.out.println("LibraryId is :" + libraryId + " and Item Id is :" + itemId);
    }

Det er mange tilgjengelige alternativer med EasyTest Library som du kan bruke til å utføre testene dine effektivt. For eksempel, hvis du ønsker å utføre testene dine parallelt, gir EasyTest en parallell merknad. Ta en titt på dette blogginnlegget for å forstå den parallelle merknaden i detalj.

Her er et annet detaljert eksempel som bruker de tilgjengelige funksjonene i EasyTest:

@RunWith(DataDrivenTestRunner.class)
    @DataLoader(filePaths = { "testExcelData.xls" })
    @Format(date='dd/MM/yyyy')
    @Report
    @Parallel(threads=5)
    public class TestExcelDataLoader{
    
      @Duration(timeInMillis=1000)
      private ItemService itemService = new RealItemService();

    @Test
    public void getExcelTestData(@Param(name="libraryId")
    Float libraryId, @Param(name="itemId")
    Float itemId) {
        System.out.print("Executing getExcelTestData :");
        System.out.println("LibraryId is :" + libraryId + " and Item Id is :" + itemId);
    }

Du kan ta en titt på kildekodens javadocs for å forstå hva hver av merknadene betyr og kan også få ideen om funksjonaliteten som er tilgjengelig i EasyTest.

Å skrive testklasser med så mange merknader på hver testklasse kan ikke bare være tidkrevende (typisk kjeleplatekode), men det kan også introdusere feil som er vanskelige å spore. Derfor gir Easytest deg muligheten til å definere en gang og bruke funksjonalitet overalt. Ta en titt på eksemplet nedenfor, som er det samme som ovenfor, men mer kortfattet:

Alternativt kan du bruke TestPolicy-annotering på klassenivå for å flytte alle merknadene til en egen gjenbrukbar Testpolicy-klasse. Her er et eksempel.

     @RunWith(DataDrivenTestRunner.class)
    @TestPolicy(TestExcelDataPolicy.class)
    public class TestExcelDataLoader{
    
      @Duration(timeInMillis=1000)
      private ItemService itemService = new RealItemService();

    @Test
    public void getExcelTestData(@Param(name="libraryId")
    Float libraryId, @Param(name="itemId")
    Float itemId) {
        System.out.print("Executing getExcelTestData :");
        System.out.println("LibraryId is :" + libraryId + " and Item Id is :" + itemId);
    }

Her, i stedet for å definere flere merknader på testklassen, har vi nettopp definert en TestPolicy Annotation som abstraherer de komplekse definisjonene fra testklassen.

Og her er hvordan policy-klassen TestExcelDataPolicy ser slik ut:

@DataLoader(filePaths = { "org/example/data/testExcelData.xls" })
     @Format(date='dd/MM/yyyy')
     @Report
     @Parallel(threads=5)
     public class TestExcelDataPolicy {
         
     }

Å ha en slik abstraksjon betyr at du nå kan gjenbruke testpolicyklassen din på flere tester, noe som reduserer kjeleplatekoden din betraktelig.

Når du har definert testklassen din, er neste trinn å definere testdatafilen.

Trinn 3 :Opprett en testdatafil (for eksempel vil det være en excel-fil med navnet testExcelData.xls)
Den første kolonnen i første rad angir navnet på testmetoden som dataene må oppgis for. 2. og tredje kolonne i 1. rad representerer navnet på inngangsparametrene til testen. Rad 2 og 3 representerer de faktiske testdataene.

getExcelTestData itemId libraryId

                         11567 91475

                          null         0

Gratulerer . Du har nettopp skrevet din første datadrevne test. Når du kjører testen ovenfor med Junit-støttet IDE, vil EasyTest generere 2 tester, en for hvert sett med data. Dermed har du nettopp spart deg selv fra å skrive forskjellige tester for testing med forskjellige parametere.

La oss deretter utvide dette eksemplet og prøve å forstå noen ekstra funksjoner i EasyTest .

Forstå IoC Container-støtten i EasyTest

I stedet for å definere/initialisere testSubject (ItemService i testen ovenfor) i selve testklassen, kan du også eksternalisere initialiseringslogikken i en konfigurasjonsfil og injisere riktig instans ved kjøring. Fordelen med å gjøre dette er at du skiller initialiseringslogikken fra testlogikken og dermed gjør testene renere og mer vedlikeholdbare. For det andre kan du gjenbruke den eksternaliserte logikken i andre tester også. La oss se hvordan vi kan gjøre det for testen ovenfor.

@RunWith(DataDrivenTestRunner.class)
    @DataLoader(filePaths = { "testExcelData.xls" })
    @TestConfigProvider({TestConfigProviderClass.class})
    public class TestExcelDataLoader{
    
      @Inject
      private ItemService itemService;

    @Test
    public void getExcelTestData(@Param(name="libraryId")
    Float libraryId, @Param(name="itemId")
    Float itemId) {
        System.out.print("Executing getExcelTestData :");
        System.out.println("LibraryId is :" + libraryId + " and Item Id is :" + itemId);
    }

Merk at vi har lagt til to ting til testene ovenfor:

  1. TestConfigProvider-kommentar
  2. Sett inn kommentar

TestConfigProvider-kommentaren tar en rekke konfigurasjonsleverandørklasser som bønnene kan lastes fra. I eksemplet ovenfor vil TestConfigProviderClass.class se slik ut:

public class TestConfigProviderClass {
    
    @TestBean public ItemService itemService(){
        return new RealItemService();
    }

Vær også oppmerksom på at vi bruker standard Javax-annotering @Inject for injeksjon av testbønnen. EasyTest støtter @Inject for injeksjon etter type, @Named sammen med @Inject for injeksjon etter navn. I tillegg støtter EasyTest også injeksjon etter feltnavn. EasyTest har også sin egen @Provided merknad i tilfeller der brukeren ikke kan eller ikke kan bruke Javax-kommentarene.

Og det avslutter dette blogginnlegget. Jeg håper jeg har vært i stand til å gi deg en interessant introduksjon av EasyTest og dens muligheter. Ta kontakt med meg på [email protected] i tilfelle du har spørsmål eller hvis du ønsker å bidra til prosjektet.

Java Tag