Mi az egység tesztelése?
Az egység tesztelése önmagában magyarázó szó, ha megértjük, hogy mit értünk az egység alatt. Az egység a lehető legkisebb kóddarab, amelyet logikailag el lehet különíteni a rendszertől. Ez azt jelenti, hogy minden olyan kóddarabot, amely bemeneteket, feladatot hajthat végre és kimenetet generálhat, még akkor is, ha független a teljes rendszertől vagy megoldástól, egységnek lehet nevezni. Ennek a kóddarabnak a tesztelését egy adott bemeneti készlet várt outputjának előállítása céljából Unit Testing-nek nevezzük.
Az egység tesztelésének típusai
Beszéljünk néhány egységteszt-típusról.
1) Kézi tesztelés
A kód manuális tesztelése megköveteli a fejlesztőtől, hogy manuálisan hibaelhárítsa a kód minden sorát, és ellenőrizze a pontosságát. Szükség lehet lépésről lépésre, ha a funkcionalitás összetett.
2) Automatizált tesztelés
Az automatizálási tesztelés során a fejlesztő kódot ír be a tesztkódhoz. Ezt általában az egységteszt-keretek segítik, amelyeket nem alkalmaznak a termelésben. Más esetekben a fejlesztő dönthet úgy, hogy tesztkódot ír fel a keret nélkül, és manuálisan kommentálja azt a telepítés előtt.
A kézi tesztelés nyilvánvalóan időigényesnek tűnik a legtöbb esetben. Egyes esetekben azonban, amikor az egyes forgatókönyvek lefedése céljából automatizált tesztelési esetek írása nem lehetséges, gyakran a manuális a preferált módszer.
Miért fontos az egység tesztelése?
Az egységteszt fontosságának megértéséhez a szélesebb képet kell megnéznünk. Ez a szoftverfejlesztési életciklus része. Röviden nézzük meg a többi részt, hogy jobban megértsük az egységteszt szerepét.
A fenti kép a szoftverfejlesztés normál életciklusának és az ahhoz kapcsolódó tesztelési folyamatok egyszerű bemutatása. Mondanom sem kell, hogy a projekt felépítésétől függően az egész folyamat bizonyos komponensek hozzáadásával és eltávolításával változik. A tesztelési eljárás azonban minden bizonnyal négy alábbit tartalmaz:
- Egység tesztelése - a teljes tesztelési folyamat elemi szintje. Ezt az alkatrész fejlesztője vagy társai hajtják végre. Ez utóbbi esetben a szoftver világában gyakran Peer Testing-nek hívják.
- Integrációs tesztelés - Az egység alkatrészének tesztelése annak közvetlen szülőmoduljával. A cél az, hogy ellenőrizze, hogy az egység alkotóeleme jól integrálódik-e a többi alkatrészhez, és nem okozott-e hibát egyetlen másik alkatrész működésében sem.
- Rendszer tesztelése - A teljes rendszer tesztelése, amikor az egység alkatrésze a helyzetében van.
- Elfogadási tesztelés - Általában üzleti vállalkozások / ügyfelek végzik, ellenőrzik, hogy az eredmény megegyezik-e a végfelhasználó által elvárt funkcionalitással.
Így nagyon jól látható, hogy az összes tesztelési folyamat az alapvető tesztelési szintre támaszkodik. Ha a tesztelés alapszintjét nem hajtják végre, akkor az összes többi vizsgálat hiábavaló lehet.
Tegyük fel, hogy van egy kódja, amely két részből áll
- Számítsa ki az összetett kamatot.
- Adja hozzá a kamatot a tőkeösszeghez, és számolja ki a lejárat előnyeit.
Tegyük fel, hogy nem tesztelte ezen elemek egyikét sem, és közvetlenül a rendszer tesztelésére folytatta. A rendszer tesztelése során hiba merül fel, hogy a lejárati érték helytelen. Most a kód melyik részén van hiba?
- Ez lehet a kamat kiszámításában.
- Ez lehet az összetett logika alkalmazásában.
- Ez kiegészítheti a kamatot a tőkeösszeggel.
Nézze meg, hogyan növeli az erőfeszítéseket most. Mindezt el lehetett volna kerülni, ha mindkét kód-összetevőt egység-tesztelésnek vettem alá.
Miért fontos az egység tesztelése?
- A hibákat csak a fejlesztési szakasz elején javítja ki. Ez sok időt, erőfeszítést és költségeket takarít meg. Képzelje el, ha nem végezne egységvizsgálatot, akkor a kód a minőségbiztosítási csapat felé fordulna, és odakerülne a nagyon egyszerű kérdésekhez.
- A jó egységteszt a részletes dokumentáció célját szolgálja. Amikor egy fejlesztő egységteszt eseteket ír, akkor véletlenül megírja a kód várható funkcionalitását. Ez egyszerűen nem más, mint a kód működését magyarázó dokumentáció.
- Megkönnyíti a kód módosítását és karbantartását. Miután módosította a kódot, futtassa újra a teszteket és a viola-t, minden hibát gond nélkül észrevegyék.
- Ezenkívül érvényesíti a modularitást. Az egységteszteket egyes komponenseken futtatják, ami azt jelenti, hogy a kódnak a lehető legfinomabbnak kell lennie. Ez biztosítja, hogy a kód megfelelően modulokra oszlik.
Az érme másik oldala
Vannak bizonyos hátrányai is. Bár az előnyök meghaladják a hátrányokat, és mindig javasoljuk, hogy tesztelje kódját, ugyanakkor érdemes ismerni ugyanazon érme mindkét oldalát.
- Az egység tesztelés, oly módon is, amilyen alapos, időnként elkerülheti az összes hibát a legfontosabb kódban is. Az összes végrehajtási út egyszerűen nem lehetséges. Így az egységteszt gyakran egyértelmű boldog út és negatív forgatókönyvek.
- Fejlesztőt igényel, hogy gondolkozzon a dobozból, és próbálja megtörni a kódját. Ez gyakran nehéz, mivel egy fejlesztő észlelése elfogult a kód felé.
Egységtesztelő eszközök
Az iparban számos eszköz létezik, amelyek segítenek az automatikus egységtesztben. A célnak köszönhetően megkönnyítik az egység tesztjeinek írását és végrehajtását a fejlesztő számára. A fejlesztők kifizetésekor létezik egységek tesztelési keretrendszere. Az alábbiakban felsoroljuk a legnépszerűbb és legszélesebb körben használt eszközöket.
JUnit
A JUnit egy ingyenesen használható tesztelő eszköz a Java számára. Ez automatikusan bekerül számos, a Java fejlesztéshez szükséges IDE-kkel elérhető sablonba. A JUnit különlegessége az, hogy először az adatokat teszteli, majd az adatok beillesztése után a kódot teszteli. Ezenkívül állításokat nyújt a vizsgálati módszerek azonosítására.
NUnit
Az NUnit a .Net, a JUnit a Java. A JUnit összes vonzó tulajdonságával rendelkezik, de a .Net programozási nyelv fejlesztéséhez. Támogatja a tesztek párhuzamos futtatását is.
PHPUnit
A JUnit és NUnithez hasonlóan a PHPUnit egy eszköz a PHP fejlesztők számára. Támogatja a jó tesztelő eszköz minden alapvető tulajdonságát is.
XUnit
Egy másik keret, amely általánosabb, mint a többi, az XUnit. Támogatja a több nyelvet, például a C ++, C #, ASP.Net, stb. Hasonló funkciókkal büszkélkedhet, mint a piacon elérhető egyéb eszközök.
Jtest
A Parasoft Jtest egy harmadik féltől származó plugin, amely kihasználja a nyílt forráskódú keretrendszereket, például a JUnit-et, és egyetlen kattintással megoldásokat ad az élet megkönnyítése érdekében. A Jtest segítségével néhány kattintással automatikusan létrehozhat tesztkódokat a kódjára. Ezen feladatok automatizálásával a fejlesztő szabadon dolgozhat a teszt esetek üzleti logikáján.
QUnit
Egy nagyon népszerű JavaScript egység tesztelési keret. Tesztelheti a JavaScript kódot mind az ügyfél, mind a szerver oldalán.
Jázmin
Egy másik nagyon széles körben használt tesztelő eszköz a JavaScript keretrendszerekhez. Jelentős közösségi támogatással rendelkezik az Angular, React stb. Számára.
JMockIt
A JMockIt egy nyílt forráskódú eszköz, amely szintén támogatja az API-hívások megragadását rögzítési és ellenőrzési szintaxissal.
Példa az egység teszt esetére
Az egységteszt esetének nagyon alapvető követelménye a vizsgált kód. Tegyük fel, hogy van olyan funkciónk, amely ellenőrzi, hogy a telefonszámok helyesek-e (formátumban), vagy sem. A földrajzi elhelyezkedéstől függően ez a kritérium is változhat. Tehát nem fogjuk hangsúlyozni a kritériumokat. Inkább az egységtesztre összpontosítunk.
public class PhoneValidator
(
public bool IsPhoneValid(string phone)
(
/* write some code to verify if the phone is valid or not. return true, if the phone is valid. return false, if invalid. */
)
)
Most ki kell tesztelnünk ezt a kódot.
Vagy manuálisan tesztelhetjük különféle értékek beillesztésével és a kimenet ellenőrzésével. Ez az első pillantáskor könnyűnek tűnhet, de ismételt feladat lesz, ha a kód módosul.
Alternatív megoldásként írhatunk egy egység teszt esetet is, amely érvényesítőként szolgálhat, amennyiben az üzleti logika változatlan marad. Az egységteszt akkor sem változik, ha megváltoztatjuk a kódot. Tehát írjunk egy egység-teszt esetet a fenti kódhoz.
public void TestPhoneValidator()
(
string validPhone = "(123) 456-7890";
string invalidPhone = "123 45"
PhoneValidator validator = new PhoneValidator();
Assert.IsTrue(validator.IsPhoneValid(valid phone));
Assert.IsFalse(validator.IsPhoneValid(invalidPhone));
)
Tehát hogyan működik a fenti egység tesztkód? Vegye figyelembe a két állítólagos állítást. Gondoskodnak arról, hogy a teszt csak akkor teljesüljön, ha a két vonal igaz és hamis érkezik a megfelelő IsPhoneValid funkcióhívásokból.
Felteszi a kérdést, hogy milyen előnyei vannak ennek a próbaverziónak az írásában? Nos, ha több ezer telefonszám van érvényesítésére bármilyen valós esetben, akkor nem kell manuálisan ellenőriznie minden alkalommal, amikor a hibakereső eltalálja a kódot. Egyszerűen hívja fel a tesztkódot több ezer alkalommal, és megmondja, melyik teszt ment át, és melyik nem sikerült. Most csak meg kell vizsgálnia a sikertelenket.
Egységtesztelési tippek
- Mindig használjon olyan eszközt vagy keretet, amely támogatja a nyelvet. Az eszközök megkönnyítik az egységteszt-esetek fejlesztését. Egyébként további erőfeszítéseket tehet a végén.
- Bár mindenre ajánlott, néha kényelmes az olyan kódokat átugorni, amelyek egyszerűek és nem befolyásolják közvetlenül a rendszer viselkedését. Például a getter és a setter kódokra kevésbé lehet koncentrálni.
- Soha ne hagyja ki azokat a kódokat, amelyek közvetlenül befolyásolják a rendszert, vagy kulcsfontosságúak az üzleti logika megvalósításához.
- Használjon teszt adatokat, amelyek hasonlóak a termelési adatokhoz.
- Válassza ki a kódját. Ha a kód az adatbázis adataitól függ, ne írjon próbapéldányt az adatbázis felhívására és az értékek lekérésére. Ehelyett hozzon létre egy felületet, és gátoljon az API- és az adatbázis-hívásokra.
- Mielőtt kijavítaná az egység teszteléséből adódó hibát, írja be a tesztet, amely feltárja a hibát. Ennek három oka van:
- Ön képes lesz arra, hogy észrevegye a javításból származó regressziós hibákat.
- A teszt eseted most átfogóbb.
- Gyakran egy fejlesztő túl lusta, hogy frissítse a tesztjeit, miután megírták.
- Az üzleti logikát ellenőrző teszt esetek írása mellett olyan esetek írása, amelyek tesztelik a kód teljesítményét is. Különösen akkor, ha a kódok hurkolást tartalmaznak, a teljesítmény a leginkább érintett terület.
Dolgok, amikre emlékezni kell
- Az egységteszt eseteknek függetleneknek kell lenniük
- Tesztelni kívánt kód - A kód bármilyen megváltoztatásához nem szükséges az egység teszt esetének megváltoztatása, kivéve ha maga az üzleti logika megváltozik. Például, ha a logika megköveteli, hogy egy érvényes telefonszámnak mindig „+” -nel kezdődjön, akkor az egység teszt esetét meg kell változtatni, különben nem.
- A másik kód - Nem lehet kölcsönhatás vagy függőség más kóddarabokkal, adatbázis-értékekkel vagy ilyen dolgokkal. A készüléket teszteléskor el kell különíteni.
- Kövesse a vizsgálati esetek világos és következetes elnevezési szabályait. Megkönnyíti a forgatókönyvek nyomon követését. Használhat verziószabályozó eszközöket is a tesztesemények nyomon követéséhez.
- Soha ne add tovább a kódot a következő fázishoz, amíg meg nem történt, a hibákat kijavítják és újra nem tesztelik.
- A legfontosabb, hogy ez szokássá váljon. Ez egy kódolási gyakorlat, amelyet be kell vonni. Minél többet kódol egységek tesztelése nélkül, annál nagyobb a hibalehetőség.
Karrier az egység tesztelésében
Bár az egység tesztelése nem egész mező, mégis ez egy további nyíl a quiver-ben. Ez jó kódolási gyakorlat, és mikor nem részesülnek előnyben a jó kódolók?
Következtetés
Vitathatatlanul arra lehet következtetni, hogy az egység tesztelése néha egyszerű és máskor összetett is lehet. Ez az, amikor az eszközök és a keretek megmentnek. A kód még az egység tesztelése után sem teljesen hibátlan. Ekkor kezdődik el a következő szintű tesztelési eljárás. Ezen bizonytalanságok között az egyetlen, hogy az egység tesztelésére van szükség.
Ajánlott cikkek
Ez egy útmutató az egység teszteléséhez. Itt a példákkal tárgyaltuk az egység tesztelésének fontosságát, tippeit, eszközeit, karrierjét és típusait. A további javasolt cikkeken keresztül további információkat is megtudhat -
- Interjúkérdések tesztelése
- Webes tesztelési alkalmazás
- Hiba az életciklus a szoftver tesztelésében
- Karrier a szoftver tesztelésében
- A Java tesztelési kereteinek listája