Szerezzen gyakorlati gyakorlatot tesztvezérelt fejlesztéssel a C # nyelven

Tehát beszéljünk a TDD-ről - mi ez?

A TDD a Test Driven Development rövidítést jelenti , és ez egy tervezési folyamat a szoftverfejlesztésben. Egy nagyon rövid fejlesztési ciklus megismétlésére támaszkodik, és a követelményeket nagyon specifikus tesztesetekké alakítják.

A TDD folyamatban van néhány lépés:

  1. Írjon sikertelen egységtesztet.
  2. Írjon annyi kódot, hogy sikeres legyen a teszt - ebben a lépésben nem érdekel a jó kód.
  3. Refactor a kódot az előző lépésből.

Milyen előnyei vannak ennek a megközelítésnek?

Először is, mielőtt megírná, jobban megismeri a tényleges kódot. Ez a TDD egyik legnagyobb előnye. Amikor először írja a teszteseteket, tisztábban gondol a rendszerkövetelményekre, és kritikusabban a sarok esetekre .

A függőségekről szólva fontos megemlíteni, hogy a TDD-vel való munka lehetővé teszi, hogy az osztályok logikájára koncentráljon. Így az összes függőséget megtartja az osztályain kívül. Fontos megemlíteni azt is, hogy a kódod biztonságosabban fog futni , mivel a logikának nem kell kezelnie a különbségfüggőségeket, például az adatbázis-kapcsolatokat, a fájlrendszereket stb.

Ez egyben biztonságosabb módszer a kód újrafrakciójára . A TDD írásakor vannak tesztek egy bizonyos logikai elemre. Amikor átdolgozza a kódot, elronthat valamit, de ezzel a megközelítéssel tudja, hogy a teszteknek hátul lesz.

A TDD használatakor gyorsabban megismerheti a kód működését is. Amikor elkezd dolgozni egy olyan kódrészleten, amelyet nem ismer, akkor elolvashatja a kódrészlet teszteseteit és megértheti annak célját. Ezek a tesztek a kódod dokumentációját is tartalmazzák.

És végül összpontosíthat a kisebb alkatrészek építésére a legjobb módon, és elkerülheti az összkép fejfájását. Tehát hogyan segít ez? Írsz egy sikertelen tesztet, és kizárólag erre koncentrálsz, hogy sikeres legyen. Kényszeríti, hogy egyszerre a funkcionalitás kisebb darabjaira gondoljon, nem pedig az alkalmazás egészére. Ezután fokozatosan építhet egy passz tesztre, ahelyett, hogy megpróbálná kezelni a nagyobb képet a get-go-ból, ami valószínűleg több hibát eredményez.

Mielőtt elkezdenénk írni a TDD-t ...

Hogy őszinte legyek, több cikk van, amelyekben még mélyebben olvashat a TDD-n. Ezért elkerültem a TDD teljes elméletének ideírását, mert nagyon sok időbe fog telni mindent elolvasni.

Ezért most ismertettem a TDD tervezési folyamat általános gondolatát és előnyeit.

Itt az ideje néhány tesztet írni, úgyhogy tegyük meg

Leírás és követelmények

A C # kóddal fogunk írni egy Stack implementációt. Miért C #? Nos, mert szeretem a C # -t, miért ne? ?

Tehát követelményeink meglehetősen egyszerűek: egy Stack osztályt akarunk bevezetni, ezért a követelmények a következők:

  1. Korlátozza a verem méretét.
  2. Elem hozzáadása. (nyom)
  3. Távolítsa el az elemet. (pop)
  4. Ellenőrizze, hogy mi volt az utolsó elem. (kandikál)
  5. Szerezd meg a verem aktuális méretét.
  6. Legyen olyan osztálya, amely bármilyen adattípust elfogad.
  7. Amikor az ügyfél meghaladja a verem méretét, megfelelő kivételt kell tennünk.

Miután megtudtuk, hogy mik a rendszer követelményei, elkezdhetjük meghatározni, hogyan fogjuk ezt megoldani. Egy tömb segítségével valósítjuk meg.

Verem megvalósítása a TDD-ben - infrastruktúra építése

A Visual Studio 2017-et használom. Ebben új projektet nyitok:

File -> New -> P projektcégek, C Hoose szom le App (.NET Framework).

Válasszon egy projekt nevet - például „Verem”.

Most egy másik projektet nyitunk csak a tesztekhez, és „StackTests” -nek hívjuk.

Nyissa meg a megoldáskutatót. Van egy projektünk, a „Stack”. Most jobb klikk a megoldás, és válassza a Hozzáadás -> Új Várh ect és choo se Class Libr Ary (.NET Framework).

Telepítsük egységtesztjeinket: kattintson a jobb gombbal a StackTests projektre, válassza a NuGet csomagok kezelése lehetőséget , lépjen a „Tallózás” lehetőségre, és telepítse a következő csomagokat:

  • NUnit
  • NUnit3TestAdapter

Vegyen fel egy új osztályt a StackTests projektbe, és hívja StackTest-nek. Most a megoldásnak így kell kinéznie:

A csomagoknak.config a következőképpen kell kinéznie:

Verem megvalósítása TDD-ben - kód beírása

Megkezdjük a tesztegységek kiírását a StackTests projektben a StackTest osztály alatt.

Mielőtt elkezdenénk írni a kódot, meg kell tanulnunk 3 fontos dolgot: TestFixture, Test és Assert.

A TestFixture az a tulajdonság, amely egy osztályt jelöl, amely teszteket és opcionálisan beállítási vagy lebontási módszereket tartalmaz.

A Test attribútum egy módszer a TestFixture osztály belsejében történő tesztként történő megjelölésére.

Az Assert osztály segítő osztályok gyűjteménye a különféle körülmények tesztelésére az egység teszteken belül. Ha a tesztelt feltétel nem teljesül, kivételt vetnek.

Importálja a „NUnit.Framework” fájlt, és tegye a [TestFixture] attribútumot az osztálydefiníció fölé.

Teremtés teszt

Oké, itt az ideje, hogy megírjuk az első függvényünket. Írunk egy létrehozási tesztet, amely létrehoz egy új objektumot a veremről, és ellenőrzi, hogy a verem mérete 0 legyen-e az elején.

Most megírtuk az első tesztünket, tehát futtassuk le.

Az eszköztáron kattintson a Teszt -> Futtatás -> Minden teszt elemre .

Ha a Test Explorer nincs megnyitva, kattintson a Test -> Windows -> Test Ex plorer elemre , és ez kibővíti a tesztfelfedezőt.

Mint látható, még a Stack osztályunkat sem definiáltuk, ezért fordítási hibát kapunk. Most írjunk annyi kódot, hogy sikeres legyen a teszt.

Készítsük el az első tesztmunkát:

  • Hozzon létre egy új osztályt a Stack projektben , és hívja ezt az osztályt „Stack” -nek. Legyen ez az osztály egy általános típusú osztály (T típus).
  • Ezt az osztályt (Stack) tömbként definiáltuk, ezért a tagmezőt T típusú tömbként definiáljuk .
  • Meg kell adnunk a verem maximális hosszát a konstruktornál, ezért létrehozunk egy konstruktort, amely méret argumentumot vesz fel.
  • És mivel megköveteljük, hogy a verem aktuális méretét bármikor megkapjuk, meghatározzuk a „Méret” tulajdonságot . Természetesen egyik sem fogja tudni megváltoztatni a méretét, ezért privát készlet lesz .

Most futtassuk újra a teszteket (ellenőrizze fent a tesztek futtatásának módját), és nézzük meg az eredményeket.

És ott tartunk, megtettük az első iterációt a TTD tervezéssel! Most kéne refrakcionálnunk a kódunkat - de ezen a ponton valójában nincs mit refrakcionálnunk, ezért haladunk előre.

Push & Pop teszt

Most a push and pop funkcionalitást akarjuk tesztelni, ezért hozzuk létre a tesztesetet.

  • A Push argumentumot vesz fel, és hozzáadja a verem tetejéhez.
  • A Pop eltávolítja az elemet a veremből, és visszaadja.

Hozzáadunk 3 elemet a veremhez, majd kivesszük az utolsó elemet. Ezen a ponton ellenőrizni fogjuk, hogy az utolsó elem pontosan melyiket várjuk el, és hogy a verem mérete csökkent-e.

Amint láthatja, a push és a pop funkciók nem is léteznek, így amikor teszteket futtatunk, hibát tapasztalunkvizsgálati eredmények. Menjünk a Stack osztályba és valósítsuk meg őket.

Futtassuk újra tesztjeinket, és bumm, minden tökéletesen működik! Az összes teszt sikeresen teljesült?

Hiba a megengedett méret túllépésekor

Szeretnénk egyedi kivételeket vetni, amikor:

  1. Nyomja meg az új elemet, amikor a verem megtelt.
  2. Pop elem, ha nincsenek elemek a veremben.

Tehát, ahogy már tudja ... mit kellene most tennünk?

Helyes! Meghatározzuk a teszteseteket, majd működésbe hozzuk a kódot.

Mint láthatja, két új egyedi kivételt kell létrehoznunk.

  • ExpenditureProhibitedException - Ez a kivétel akkor következik be, amikor a verem üres, és az ügyfél megpróbál új elemet kibontani.
  • ExceededSizeException - Ez a kivétel akkor következik be, amikor a verem megtelt, és az ügyfél megpróbál új elemet hozzáadni a veremhez.

Lépjen a Stack Projectbe, és hozzon létre egy új osztályt CustomExceptions néven . Ebben az osztályban meghatározzuk az új kivételeket, amelyek örökölni fogják a Kivétel osztályt.

Módosítsa a jelenlegi push and pop funkciónkat, hogy szükség esetén kivételt képezzen.

Tehát most, a TDD életciklusának részeként, lefuttatjuk a teszteket ... és Hurrá! Minden teszt sikeresen teljesült.

Kukucskál az utolsó elem

Hamarosan befejezzük az utolsó teszteket. A verem utolsó elemét akarjuk bekukkantani. Ha a verem üres, akkor dobunk egy ExpenditureProhibitedException kivételt, különben az utolsó elemet adjuk vissza.

Készítsük el teszteseteinket.

  1. Kísérlet megpillantani az elemet, ha a verem üres. Ebben a tesztben egyedi kivételt vetünk fel.
  2. Helyezzen be néhány elemet a verembe, majd nézzen meg egy elemet, ellenőrizze, hogy ez a megfelelő elem, és ellenőrizze, hogy a tömb mérete nem változott-e.

Amikor lefuttatjuk a teszteket, nem fognak sikerülni - a peek módszer még nem is létezik, és nincs funkció.

Majd hozzon létre a funkció Peek a Stack osztály .

Most, amikor újra lefuttatjuk a teszteket, láthatjuk, hogy mindegyik sikeresen átmegy.

Összefoglalva

Amint láthatja, az ötlet nem bonyolult, és számos eszköz segíti a TDD-elvek megvalósítását.

A teljes kódot a Pastebin oldalon tekintheti meg.

Verem osztály - Ez az osztály tartalmazza a verem összes megvalósítását.

StackTests osztály - Az összes tesztesetet tartalmazza.

CustomExceptions osztályok - A TDD tervezéséhez szükséges rendszer kivételeit tartalmazza.

Minden megjegyzést és visszajelzést szívesen fogadunk - ha szükséges, kijavítom a cikket.

Lépjen kapcsolatba velem közvetlenül a LinkedIn-en - kattintson ide.