„Egységtesztelés” változatai közötti eltérés

Az egységtesztek általában [[Tesztautomatizálás|automatizált]] tesztek, amelyeket a [[Szoftverfejlesztő|szoftverfejlesztők]] írnak és futtatnak annak biztosítása érdekében, hogy egy adott alkalmazás adott szakasza (úgynevezett "egység") megfeleljen a kialakításának és az elvárt, kívánt módon viselkedjen. A [[procedurális programozás]]<nowiki/>ban az egység lehet egy teljes modul, de túlnyomórészt egyéni függvény vagy eljárás. [[Objektumorientált programozás]] során az egység gyakran egy teljes felület/interfész, például egy osztály, de lehet egyedi metódus is. Azáltal, hogyha a tesztek készítése először a legkisebb tesztelhető egységekre történik, majd az azok közötti összetett, egész viselkedésre, átfogó tesztek hozhatók létre komplex alkalmazásokhoz.

Az egységtesztek írása és fenntartása gyorsabban kivitelezhető, mint a paraméterezett tesztek esetén. Ezek lehetővé teszik egy teszt többszöri végrehajtását különböző bemeneti halmazokkal, csökkentve ezzel a tesztkód reprodukálását. A hagyományos egyéségtesztektőlegységtesztektől eltérően , amik általában zárt metódusok és invariáns körülményeket tesztelnek, a paraméterezett tesztek bármilyen paraméterkészletet felvehetnek. A paraméterezett teszteket támogatja a [[TestNG]], [[JUnit]] és ennek .NET-beli párja, az [[xUnit]] is. Az egységteszthez tartozó megfelelő paraméterek manuálisan is megadhatók, vagy egyes esetekben a teszt keretrendszere automatikusan generálja őket. Az utóbbi években támogatták az erőteljesebb (egység) tesztek írását, az elméletek koncepciójának kiaknázását, az olyan teszteseteket, amelyek ugyanazokat a lépéseket hajtják végre, de a futási idő alatt generált teszt adatokattesztadatokat használnak, ellentétben a szokásos paraméterezett teszttel, amely ugyanazokat a végrehajtási lépéseket használja olyan bemeneti halmazokkal, amelyek előre definiáltak.

Az egységtesztelés a [[szoftverfejlesztési folyamat]] korai szakaszában találja meg a problémákat. Ez egyaránt magában foglalja mind a programozó végrehajtásának [[Bug (informatika)|bugjait]], mind az egység specifikációjának hibáit vagy annak hiányzó részeit. Az alapos, részletes tesztkészlet megírásának folyamata arra készteti a fejlesztőt, hogy gondolja át a bemeneteket, a kimeneteket és a hibafeltételeket, ezáltal így pontosabban meghatározza az egység kívánt viselkedését. A hibakeresés költsége a kódolás megkezdése vagy a kód első írása előtt jóval alacsonyabb, mint a hiba későbbi felismerésének, azonosításának és kijavításának költsége. A kiadott kódban szereplő hibák szintén költséges problémákat okozhatnak a szoftver végfelhasználói számára. A kódra lehetetlen vagy bonyolult egység tesztetegységtesztet írni, ha az rosszul van megírva, így az egységtesztelés arra készteti a fejlesztőket, hogy jobban strukturálják a funkciókat és az objektumokat.

Az egységteszt lehetővé teszi a programozó számára a [[Kódrefaktorálás|kódrefaktorálást]] vagy a rendszerkönyvtárak egy későbbi időpontban történő frissítését és a modul továbbra is helyes működéséről való megbizonyosodást(például [[Regressziós tesztelés|regressziós teszteléskor]]). A művelet során tesztesetek írására kerül sor minden [[Függvény (programozás)|függvényre]] és [[Metódus (programozás)|metódusra]] azért, hogyha bármilyen változás hibát okozna, az gyorsan azonosítható legyen. Az egységtesztek olyan változásokat észlelnek és derítenek ki, amelyek megsérthetik a [[Szerződésalapú programozás|szerződésalapú tervezést]].

A szoftvertesztelés egy kombinatorikus probléma. Például, minden Boolean döntési nyilatkozatnak legalább két tesztre van szüksége: egy „igaz” és egy „hamis” kimenetelűre. Ennek eredményeként a programozóknak minden megírt kódsorra 3–5 sornyi tesztkódra van szükségük. Ez nyilvánvalóan időt vesz igénybe és esetleg nem is éri meg a belefektetett erőfeszítést. Vannak olyan problémák, amelyeket egyáltalán nem könnyű tesztelni - például nemdeterminisztikus [[Algoritmus|algoritmusok]], vagy több [[Szál (programozás)|szálat]] tartalmaznak. Továbbá, az egységteszt kódja valószínűleg legalább olyannyira hibás (buggy), mint az a kód, amit tesztelni hivatott. [[Fred Brooks]] a ''[[The Mythical Man Month]]'' című könyvében eképpen szól:,,Soha ne menj a tengerre két kronométerrel; vigyél kettőt vagy hármat.” Ugyanis, ha két kronométer ellentmond, akkor honnan tudod, hogy melyik a helyes?

Az egységtesztelés előnyeinek eléréséhez szigorú fegyelemre van szükség az egész szoftverfejlesztési folyamat során. Alapvető fontosságú, hogy ne csak az elvégzett teszteket, hanem a szoftver ezen vagy bármely más egységének forráskódjában elvégzett változtatásokat is gondosan rögzítsük. Lényeges egy [[Verziókezelés|verziókezelő]] rendszer használata is. Ha az egység egy későbbi verziója elbukik egy olyan sajátos tesztetteszten, amin korábban átment, akkor a verziókezelő szoftver a forráskód-változtatások (ha vannak) listáját képes nyújtani, amelyek az egységre azóta vonatkoznak.

Az egységtesztek általában akkor a legkönnyebbek, ha a metódusnak néhány paramétere és valamilyen kimenete van. Nem ilyen könnyű olyan egységteszteket készíteni, amikor a metódus fő függvénye kölcsönhatásban van valamivalamilyen alkalmazáson kívüli dologgal. Például egy adatbázissal dolgozó metódusnál szükség lehet egy ''replikára'' (mock up) az adatbázis-interakciók modelljének létrehozására, amely valószínűleg nem lesz olyan átfogó és széleskörű, mint a valódi adatbázis-interakciók.

Az alábbiakban [[Java (programozási nyelv)|Java]] nyelven megvalósított teszteset sorozat látható, amely meghatározza egy elemszámát az implementációnak. Először is, rendelkezni kell egy Hozzáadó (Adder) nevű interfésszel, ami egy hozzáad(add) nevű függvényt tartalmaz, valamint egy HozzáadóImpl nevű, paraméter nélküli konstruktort tartalmazó implementáló osztállyal, ami a Hozzáadó interfészt implementálja. Ezt követően azt kell ellenőrizni, hogy a 2 egész szám típusú bemeneti paraméterrel felruházott hozzáad(add) metódus az egész szám kimenetében ezen paramétereinek helyesen összeadott összegével tér-e vissza. Ez az ellenőrzés az [[Állítás (programozás)|állítás]] (assertion) segítségével valósítható meg, mely tulajdonképpen egy predikátum, egy olyan logikai függvény, mely hozzájárul a program hibáinak felismeréséhez. Az assert kimenete igaz vagy hamis lehet, ami arra szolgál, hogy jelezze, hogy jelen esetben a paramétereként megadott metódus (hozzáad) a kívánt módon működik-e. A metódus viselkedése meghatározásra kerül egy kisebb értékhalmazzal és különböző számú tesztekkel. Jelen esetben ez azt jelenti, hogy össze tud-e adni helyes eredménnyel 2 számot, legyen az akár pozitív, akár negatív, akár nagyobb értékkel bíró vagy nulla; itt, ha az assert igazzal tér vissza, akkor a példafüggvény helyesen, különben helytelenül működik. <syntaxhighlight lang="java">

Az egységtesztelés az [[extrém programozás]] sarokköve, amely egy automatizált [[Egységteszt keretrendszerek listája|egységteszt keretrendszerre]] támaszkodik. Ez az automatizált egységtesztelési keretrendszer lehet harmadik fél, például az [[xUnit]], vagy létrehozható a fejlesztői csoporton belül.7

Az extrém programozás egységtesztek létrehozását használja a [[Tesztvezérelt fejlesztés|tesztvezérelt fejlesztéshez]]. A fejlesztő egy egységtesztet ír, amely vagy egy szoftverkövetelményt, vagy egy hiányosságot fejt ki. Ez a teszt sikertelen lesz, mert vagy a követelményt még nem implementálták a kódban, vagy azért, mert szándékosan feltárja a már meglévő, megírt kód hibáját. Ezután a fejlesztő a legegyszerűbb kódot írja, hogy a teszt, más tesztekkel együtt, sikeres legyen.

Egy rendszerben a legtöbb kód egységteszt alá van vetve, de nem feltétlen minden útja a kódnak. Az extrém programozás megköveteli a "Tesztelj mindent, ami esetleg megszakad!" stratégiát, túl a hagyományos "Tesztelj minden végrehajtási utat!" módszeren. Ez arra készteti a fejlesztőket, hogy kevesebb tesztet dolgozzanak ki, mint a klasszikus módszereknél, de ez nem igazán probléma, inkább a tény újra megfogalmazása, mivel a klasszikus módszerek ritkán voltak elég módszeresen követve ahhoz, hogy minden végrehajtási útvonalat alaposan megvizsgáljanak.

A tesztkód egy első osztályú projekt ''műalkotásnak/készítménynek'' (artifact) tekinthető, abban a tekintetben, hogy ugyanolyan minőségben tartják fent, mint az implementációs kódot. A fejlesztők a tesztelt kóddal együtt az egységteszt kódot is kiadják a ''tárolóba'' (repository). Az extrém programozás alapos egységtesztelése lehetővé teszi a fent említett előnyöket, például az egyszerűbb és magabiztosabb kódfejlesztést és -[[Kódrefaktorálás|refaktorálást]], egyszerűsített kódintegrációt, pontos dokumentációt és több modulárismodulárisabb felépítést. Ezek az egységtesztek állandóan futtatva vannak [[Regressziós tesztelés|regressziós teszt]] formájában is.

=== Nyelv-szintű egységtesztelés támogatás ===

Ez a szócikk részben vagy egészben a ''[[:en:Unit_testing|Unit testing]]'' című angol Wikipédia-szócikk [https://en.wikipedia.org/w/index.php?title=Unit_testing&oldid=956147011 ezen változatának] fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. <br />