[Javalist] Teszt lefedettség

[István Viczián]

Szia,

Egy nyelvet beszélünk. Pl. van egy egyszerű Spring-es crud-os
alkalmazás. Ott az osztályok metódusait nem lehet elrontani, kb. 2-3
sorosak. Amit el lehet rontani: rossz dependency injection, rossz
annotációk, rossz tranzakciós kontextus, elírt named query, rossz
onetomany annotációk, rosszul épül fel a context, stb. Erre én akarok
teszt eseteket írni, de egy ilyen metódusra viszont nem akarok unit
tesztet:

    @Override
    public List<Rendszer>
listRendszerekByRendszerCsoport(RendszerCsoport rendszerCsoport) {
        return em.createNamedQuery("listRendszerekByRendszerCsoport")
                .setParameter("rendszerCsoport",
rendszerCsoport).getResultList();
    }

Kérlek, a magyar elnevezésekről külön flame thread-et indítsunk.

Üdv,
--
Viczián István


2012/9/12 Tamás Viktor <viktor.tamas at gmail.com>:
>> 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
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist