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

  1. Számítsa ki az összetett kamatot.
  2. 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?

  1. Ez lehet a kamat kiszámításában.
  2. Ez lehet az összetett logika alkalmazásában.
  3. 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

  1. 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.
  2. 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.
  3. 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.
  4. Használjon teszt adatokat, amelyek hasonlóak a termelési adatokhoz.
  5. 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.
  6. 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.
  7. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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 -

  1. Interjúkérdések tesztelése
  2. Webes tesztelési alkalmazás
  3. Hiba az életciklus a szoftver tesztelésében
  4. Karrier a szoftver tesztelésében
  5. A Java tesztelési kereteinek listája

Kategória: