[Javalist] Teszt lefedettség

[Tamás Viktor]

> Hogy hívod az a tesztet, mely még a fejlesztői környezetben fut, de az
> osztályok együttműködését teszteli?
Ez egy nagyon jó kérdés!
Ha szigorúan akarjuk venni a unit teszt definícióját, akkor azok nem
alkalmasak erre, de mivel fejlesztői környezetben akarjuk futtatni
(tehát nincs sehova deployolva, esetleg össze sincs csomagolva
jar/ear/war-ba) mégiscsak az adódik ki, hogy technikailag unit teszt
kell hogy legyen.
Én szoktan írni ilyen "unit teszteket". Összerakom az alkalmazás vázát
és valódi külső ingereket szimulálok. Pl. meghívom a szervlet doGet
metódusát.
Ezek a tesztek viszont valamivel lassabban futnak mint a
konvencionális unit tesztek, nehezebben karbantarthatóak,
érzékenyebbek a kód változtatásaira azaz könnyebben törnek és nehezebb
őket javítani.
Simán beléjük lehet kötni, hogy "hát ezek meg miféle unit tesztek"?
V

2012/9/11 István Viczián <viczian.istvan at gmail.com>:
> Szia,
>
> Akkor ha jól értem a te terminológiád:
> unit teszt = egy osztály tesztelése
> Integrációs teszt: integrációs környezetben többi komponensekkel
>
> Hogy hívod az a tesztet, mely még a fejlesztői környezetben fut, de az
> osztályok együttműködését teszteli?
> --
> Viczián István
>
>
> 2012/9/11  <auth.gabor at javaforum.hu>:
>> Hi,
>>
>>> Szigorú vagy. :)
>>
>>   :)
>>
>>> Szerintem unit tesztnél érdemes megnézni egy osztályon belül a
>>> metódusokat és a metódusokon belül az lehetséges lefutási ágakat.
>>> Integrációsnál szerintem érdemes azt, hogy mely osztályokat, tehát nem
>>> kell olyan mélyre fúrni, mint az előbbi esetben, de van értelme
>>> megnézni. Hiszen itt a komponensek egymással való együttműködését
>>> vizsgálod, azaz hasznos információ, hogy mely komponensekre fut le.
>>> Pár ezer osztálynál már nem olyan triviális.
>>
>>   Jah, de integrációs teszt szintjén az már nem kell érdekeljen, hogy egy
>> hozzáírt kódsor vajon melyik integrációs teszt során fog lefutni, az
>> integrációs tesztek nem erről szólnak.
>>
>>> Viktor levelével értek egyet. :) Az a dolog, hogy megnézd, hogy mely
>>> unit vagy integrációs teszteket érint egy kódmódosítás, és azokat pl.
>>> előre venni jó ötlet, a Clover-ben is benne van. Utána mehet a többi.
>>> Ha a zeroturnaround marketingese lennék, akkor levezetném, hogy ha van
>>> 10 perces teszt futásod, és átlagban az 5. percben jön ki a hiba, de
>>> ezt használva már átlagban az 1.5. percben kijön, akkor napi 20
>>> builddel számolva kb. hány percet takarítasz meg. :)))
>>
>>   Először tisztázzuk, hogy mit is nevezünk integrációs tesztnek... :)
>>
>>   Integrációs tesztet az ember nem futtat minden kódmódosítás után, hanem
>> akkor futtat, amikor a fejlesztői környezetből az integrációs
>> környezetbe kerül a csomagja, ahol már együtt kell működni a többi
>> komponenssel. Szerintem... :)
>> --
>> Auth Gábor
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist