A számítógépes programozásban az egység teszt (vagy angolul " TU ", vagy " UT ") olyan eljárás, amely lehetővé teszi a szoftver egy adott részének vagy a program egy részének (az úgynevezett "egységnek") a megfelelő működését. vagy „modul”).
A nem kritikus alkalmazásokban az egység tesztek írása régóta mellékes feladat. Az Extreme Programming (XP) vagy a Test Driven Development (TDD) módszerek azonban az egységtesztelést, az úgynevezett „programozói teszteket” visszatették a programozási tevékenység középpontjába.
Ban létrehozott SUnit tesztkörnyezet a Smalltalk nyelvhez1994. októberírta Kent Beck . 1997-ben Kent Beck találkozott Erich Gammával , akivel megalkotta a JUnit-et, amely népszerűségével számos egység tesztelési keretrendszer létrehozásához vezetett . Ezt a készletet xUnit- nek hívják .
Ugyanakkor kifejlesztették az ATTOL Unit tesztet, amelyet a Sextant Avionique 1998-ban használt
Tesztet írunk, hogy összehasonlítsuk a megvalósítást annak specifikációjával. A teszt meghatározza a leállítási kritériumot (állapot vagy kimenetek a végrehajtás végén), és lehetővé teszi az ellenőrzés sikerességének vagy kudarcának eldöntését. A specifikációnak köszönhetően egy adott bemeneti állapotot össze lehet hangolni egy eredménnyel vagy egy kimenettel. A teszt lehetővé teszi annak ellenőrzését, hogy a specifikációban megadott bemeneti / kimeneti kapcsolat valóban megvalósul-e.
Az XP módszer javasolja a tesztek egyidejű megírását, vagy akár a tesztelendő funkció ( Test Driven Development ) előtt. Ez lehetővé teszi a fejlesztendő modul interfészének pontos meghatározását. A teszteket a fejlesztés során futtatják, lehetővé téve, hogy a frissen írt kód megfelel-e a követelménynek.
A program módosításakor az egységtesztek jelentenek minden regressziót . Bizonyos tesztek egy módosítás után meghiúsulhatnak, ezért vagy át kell írni a tesztet, hogy az megfeleljen az új elvárásoknak, vagy pedig kijavítani a kód hibáját.
Az egységtesztek az API kiegészítéseként használhatók, nagyon hasznos elolvasni a teszteket, hogy megértsük a módszer használatát. Ezenkívül lehetséges, hogy a dokumentáció már nem naprakész, de maguk a tesztek is megfelelnek az alkalmazás valóságának.
Általában 4 fázist határozunk meg az egység teszt végrehajtása során:
Ennek célja, hogy a programozó teszteljen egy modult , a program többi részétől függetlenül, annak biztosítása érdekében, hogy az megfeleljen a funkcionális előírásoknak, és hogy minden körülmények között megfelelően működjön. Ezt az ellenőrzést elengedhetetlennek tartják, különösen kritikus alkalmazásokban. Általában a kód lefedettségének ellenőrzése (a strukturális lefedettség értékelése) kíséri , amely abból áll, hogy az összes teszt a kódban található utasítások összes (vagy meghatározott töredékének) végrehajtásához vezet.
Az összes egységtesztet a kód módosítása után újra el kell játszani annak ellenőrzése érdekében, hogy nincsenek-e regressziók (új diszfunkciók megjelenése). Egy adott "tesztstratégia" használata korlátozhatja az újrajátszandó teszteket, például: a módosítások hatáselemzése, összefüggésben a modulok függetlenségének igazolásával, lehetővé teszi az újrajátszandó egységes tesztek célzását.
A tesztnek meg kell felelnie az alkalmazás specifikációinak, ezért először meg kell írnia a teszteket, majd később át kell adnia azokat, nem pedig a kód megírása előtt, és kockáztatnia kell, hogy befolyásolja az írás tesztjei alatt. Bob Martin, a TDD módszer nagyszerű védője, egyszerű modellt kínál az egység tesztek megírásához:
Az álok olyan objektumok, amelyek egy valós objektumot vezérelt módon szimulálnak. Bizonyos esetekben a modell használata elengedhetetlen a kód lefedettségének megtakarításához és a teszt megbízhatóságához.
A gúttal való visszaélésnek azonban ellenkező hatása lehet, beleértve a teszt végrehajtási idejének meghosszabbítását, ami a tesztek megértését bonyolulttá teszi.
Az xUnit család legtöbb keretrendszere lehetővé teszi az egység teszt osztályok létrehozását. Ezek a keretrendszerek azonban csak az osztályok vázát nyújtják. A teszteket ezért a fejlesztőnek kell megírnia.
Az egységtesztek generálása fontos téma a kutatók számára, és számos konferencia érdekli ezt a kérdést, mint például a Szoftvertesztelés és -elemzés Nemzetközi Szimpóziumát (ISSTA), Nemzetközi Szoftvertechnikai Konferenciát (ICSE) és Automatizált Szoftvertechnikát (ASE).
A program kódjának módosításakor egyes tesztek már nem felelnek meg; ebben az esetben a fejlesztőnek meg kell határoznia, hogy magából a kódból vagy a tesztből származik-e: ha a tesztből származik, akkor a fejlesztőnek módosítania kell a tesztjét, mert annak törlése növelné a program regressziójának esélyét. Egyes kutatók eszközöket fejlesztettek ki a probléma megoldására.
A ReAssert egy olyan eszköz, amely egy sikertelen teszt javítását javasolja, elemzi a módosítások tesztjeit, és változtatásokat javasol a fejlesztőnek, ha a javaslat megfelel a fejlesztőnek, egy gombnyomással elvégezhetik a változtatást.
A paraméterezhető egységtesztek olyan egységtesztek, amelyek paramétereket vesznek fel. Ezután olyan eszközöket használhatnak, mint a QuickCheck, a paraméterek előállításához. Ezek a tesztek által támogatott JUnit , testng és NUnit.
A konkrét bemeneti és kimeneti esetekre, az Oracle-generációra és a teszt lefedettségre támaszkodva az esetek minimalizálása érdekében a kutatóknak sikerült konfigurálható egységteszteket létrehozni. A módszer eredményei ígéretesek.
Eszköztárak ( keretrendszer ) sokasága teszi lehetővé az egységek tesztelését. A fő programozási nyelveken léteznek . Például Test::More a Perl .
Az „ xUnit ” általános kifejezés olyan eszközt jelöl, amely lehetővé teszi az egységtesztek elvégzését egy adott nyelven (amelynek kezdőbetűje általában az „x” helyébe lép).
Különböző eszközök teszik lehetővé az egységtesztek automatizálását: