[Javalist] Teszt lefedettség

[István Viczián]

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.

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. :)))
--
Viczián István


2012/9/11  <auth.gabor at javaforum.hu>:
> Hi,
>
>> Miért is ne lenne az? :)
>
>   Szerény véleményem szerint a code coverage jellegű tesztek unit tesztek,
> ott van értelme azt nézni, hogy egy teszteset a hozzá tartozó kódbázison
> mekkora mennyiségű kódot mozgat meg és minden döntési ágon megfelelő
> számban átmegy-e.
>
>   Az integrációs tesztnél érdekelhet, hogy mekkora kódot jár be egy-egy
> teszteset, de nem ott kellene azt az összefüggést kideríteni, kezelni és
> követni, hogy egy sornyi kódmódosítás melyik integrációs tesztet érinti,
> mert a hiba már a unit tesztnél ki kell derüljön...
> --
> Auth Gábor
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist