2012. június 1., péntek

Privát metódus tesztelése

Talán nem vagyok otthon a tesztelés világában annyira, mégis valamin megakadt a szemem.

Próbáltam lekövetni, hogy egy adott metódust mi hívja, és rohadtul privátnak tűnt...mégis protectedként szerepelt, amit elsőre nem értettem. Kiderült, hogy még egy helyről hívják a saját osztályán kívül: egy tesztből. 

Noha a teszteket nem ismerem, az objektum-orientáltság mellett annál inkább elkötelezett vagyok, így azt, hogy egy privát metódust egy teszt kedvéért protecteddé lazítsunk, egyszerűen elfogadhatatlannak tartom. Arról van szó ugyanis, hogy a teszt ugyanolyan package-ben volt, mint a tesztelt osztály, ezért elérte a protected metódust. Persze felmerül a kérdés (ami amúgy általában csak különböző kvízek vagy vizsgasorok közt), hogy miért protected akkor már, és miért nem default? Utóbbi kicsit korlátozóbb, körül-belül hasonló értelemmel, mint amit itt kihasználnak (sokan eleve vitatják a default viselkedés létjogosultságát). 
Az a tippen elsőre, hogy a felhasználó nem ismeri a pontos különbséget a "semmi" (default) és a protected közt. A másik az, hogy mivel a kezdő és a rossz fejlesztő nem ismeri a különbséget, ezért tudatos a döntés a protected mellett, nehogy összezavarják azokat - ez kicsit kicsavart magyarázat, keep it simple, akkor is, ha hülyeség.

Térjünk vissza azonban az eredeti kérdésre.

Lehet-e létjogosultsága annak, hogy közvetlenül egy teszt kedvéért módosítsuk a láthatóságot? Azaz: van-e a létjogosultsága a privát metódus tesztelésének?

Esetleg reflection-nel tesztelni, ha minden kötél szakad?

Próbáltam magamban érveket találni a fentiekre, de igazán erőset nem sikerült. A véleményem az, hogy egy ilyen eshetőség mindig a rossz tervezés eredménye, tehát minden privát metódust le kell tudni fedni az őt használó publikus interfész felől (bármelyik ágban is bújjon meg). 

Az adott esetben például az volt az érzésem, hogy a privát metódus hívása előtt egy csomó más hívás történik, ami csak az objektum megfelelő felinicializálása (talán felesleges az igekötő), felmockolása esetén fut le hibátlanul, és mivel ezt lusta volt a fejlesztő megtenni, egyszerűen átállította protectedre a vizsgált metódust, a többit meg leszarta.

Szóval - talán olvassa ezt legalább egy vagy két tesztelő, legalább egy vagy két fejlesztő - véleményeket szeretnék kérni a hozzászólások közt az egyáltalán nem költői kérdésekre.

Kösz :)

3 megjegyzés:

  1. Sok helyen láttam hogy teszt kedvéért lazítanak az elérhetőségen... nemtom, gondolom a helyzettől függ..
    lehetne mockolni csak talán bonyolult lenne azért az egy metódusért
    reflection? talán az is
    egyébként meg gondolom kb senki se nézi rajtad kívül, csak h public / nem public :)

    VálaszTörlés
    Válaszok
    1. SZVSZ inner classból amúgy látható/tesztelhető a private method - ámbár nem elegáns ez sem. Egyébként gondolom csak addig van szükség a tesztre, amíg valamilyen más interfacen nem lehet meghajtani a metódust, ezért a láthatóságon engedni biztos h bad practice.
      De amíg nem valami szuper secure követelmények vannak, addig nem túl fontos ez a kérdés.

      Törlés
  2. hm, nem biztos, hogy ertem ezt az inner classt. minek az inner class-ja?
    meg az utolso mondatot sem ertem, melyik kerdes nem fontos a szuper secure kovetelmenyek fuggvenyeben? hogy bad practice megoldasokkal rakom tele a kodot? vagy mire gondolsz?

    VálaszTörlés