mi az a Tesztvezérelt fejlesztés (TDD)?

large__8282043567 a Tesztvezérelt fejlesztés olyan folyamat, amely nagyon rövid fejlesztési ciklus ismétlésén alapul. Az Extreme Programming (XP) tesztelésen alapuló koncepcióján alapul, amely magas szintű bizalommal ösztönzi az egyszerű tervezést.

a TDD végrehajtásának eljárása a következő:

  1. írjon egy tesztet
  2. futtasson minden tesztet
  3. írja be a végrehajtási kódot
  4. futtasson minden tesztet
  5. Refaktor

ezt az eljárást gyakran piros-zöld-Refaktornak hívják.

a tesztek írása közben piros állapotban vagyunk. Mivel a tesztet a tényleges megvalósítás előtt írják, állítólag kudarcot vall. Ha nem, akkor a teszt rossz. Leír valamit, ami már létezik, vagy helytelenül írták. A tesztek írása közben zöldben lenni a hamis pozitív jele. Az ilyen teszteket el kell távolítani vagy újra kell dolgozni.

következik a zöld állapot. Amikor az utolsó teszt végrehajtása befejeződött, minden tesztnek meg kell felelnie. Ha nem, akkor a végrehajtás hibás, és javítani kell.

az ötlet nem az, hogy a megvalósítás végleges legyen, hanem hogy csak annyi kódot adjon meg a tesztekhez. Miután minden zöld, folytathatjuk a meglévő kód refaktorálását. Ez azt jelenti, hogy a kódot optimálisabbá tesszük új funkciók bevezetése nélkül. Amíg a refaktorálás a helyén van, minden tesztnek folyamatosan el kell haladnia. Ha egyikük meghibásodik, a refactor megszakította a meglévő funkciókat. A refaktorálás nem tartalmazhat új teszteket.

a sebesség a kulcs

large_5836417589
én inkább látni TDD, mint egy játék ping-pong (vagy asztalitenisz). A játék nagyon gyors. Ugyanez igaz a TDD-re is. Általában nem töltök több mint egy percet az asztal mindkét oldalán (teszt és megvalósítás). Írj egy rövid tesztet és futtasd (ping), írd meg a végrehajtást és futtasd az összes tesztet (pong), írj egy másik tesztet (ping), írd le a teszt végrehajtását (pong), refaktor és erősítsd meg, hogy minden teszt sikeres (pontszám), ismételje meg. Ping, pong, ping, pong, ping, pong, pontszám, szolgálja újra. Ne próbálja meg elkészíteni a tökéletes kódot. Ehelyett próbálja meg addig gördíteni a labdát, amíg úgy gondolja, hogy itt az ideje a gólszerzésnek (refaktor).

nem a tesztelésről van szó

T a TDD-ben gyakran félreértik. A TDD az, ahogyan megközelítjük a tervezést. Ez a módja annak, hogy a kód írása előtt gondolkodjunk a megvalósításról. Ez a módszer a kód jobb felépítésére. Ez nem azt jelenti, hogy a TDD használatából származó tesztek haszontalanok. Távolról sem. Nagyon hasznosak, és lehetővé teszik számunkra, hogy nagy sebességgel fejlődjünk anélkül, hogy félnénk, hogy valami elromlik. Ez különösen igaz, ha a refaktorálás történik. A kód átszervezése, miközben bízik abban, hogy egyetlen funkció sem sérül meg, óriási lendületet ad a kód minőségének.

a TDD fő célja a kódtervezés tesztekkel, mint nagyon hasznos melléktermék.

gúnyos

annak érdekében, hogy a tesztek gyorsan futhassanak, így állandó visszacsatolást biztosítsanak, a kódot úgy kell megszervezni, hogy a módszerek, funkciók és osztályok könnyen kigúnyolhatók és beakaszthatók legyenek. A végrehajtás sebességét súlyosan befolyásolja, például tesztjeinknek kommunikálniuk kell az adatbázissal. A külső függőségek kigúnyolásával képesek vagyunk drasztikusan növelni ezt a sebességet. Egész egység tesztek suite végrehajtását kell mérni percben, ha nem másodpercben. Ami még fontosabb, mint a sebesség, a kód megtervezése oly módon, hogy könnyen kigúnyolható és elfojtható legyen, arra kényszerít minket, hogy jobban strukturáljuk ezt a kódot az aggodalmak szétválasztásával. Gúnyokkal vagy anélkül a kódot úgy kell megírni, hogy például könnyen kicserélhessük az egyik adatbázist a másikra. Ez a “másik” lehet például gúnyolt vagy memóriában lévő adatbázis.

egy példa a Scala gúnyolódására a Scala Test-Driven Development (TDD): Unit Testing File Operations with Specs2 and Mockito cikkben található. Ha a választott programozási nyelv Nem a Scala, A cikk továbbra is nagyon hasznos lehet A bármely nyelvre alkalmazható minta megtekintéséhez.

figyelők

nagyon hasznos eszköz, ha dolgozik a TDD divat figyelők. Ezek olyan keretek vagy eszközök, amelyeket a munka megkezdése előtt hajtanak végre, és figyelik a kód bármilyen változását. Ha ilyen változást észlel, az összes teszt fut. JavaScript esetén szinte minden build rendszer és feladat futtató lehetővé teszi ezt. A Gulp (a kedvencem) és a Grunt két példa a sok közül. Scala van sbt-revolver (többek között). A legtöbb más programozási nyelv rendelkezik hasonló eszközökkel, amelyek újrafordítják (ha szükséges), és lefuttatják az összes (vagy érintett) tesztet, amikor a kód megváltozik. Mindig úgy végzem, hogy a képernyőm két ablakra oszlik. Az egyik a kóddal, amelyen dolgozom, a másik pedig a folyamatosan végrehajtott tesztek eredményeivel. Csak annyit kell tennem, hogy figyelek arra, hogy ezeknek a figyelőknek a kimenete megfeleljen annak a fázisnak, amelyben vagyok (piros vagy zöld).

dokumentáció

a TDD (és általában a jól strukturált tesztek) másik nagyon hasznos mellékhatása a dokumentáció. A legtöbb esetben sokkal könnyebb megtudni, hogy mit csinál a kód a tesztek megtekintésével, mint maga a megvalósítás. További előny, amelyet más típusú dokumentáció nem tud nyújtani, az, hogy a tesztek soha nem elavultak. Ha bármilyen eltérés van a tesztek és az implementációs kód között, a tesztek sikertelenek. A sikertelen tesztek pontatlan dokumentációt jelentenek.

tesztek dokumentációként cikk egy kicsit mélyebb érvelést nyújt a tesztek használata mögött a hagyományos dokumentáció helyett.

Összegzés

tapasztalatom szerint a TDD valószínűleg a legfontosabb eszköz a szoftver eszköztárunkban. Sok időt és türelmet igényel, hogy jártas legyen a TDD-ben, de ha ezt a művészetet elsajátítják, a termelékenység és a minőség drasztikusan növekszik. A TDD megtanulásának és gyakorlásának legjobb módja a páros programozás. Mint egy ping-pong játékban, amely két résztvevőt igényel, a TDD párban is lehet, ahol az egyik kódoló teszteket ír, a másik pedig e tesztek végrehajtását írja. A szerepek minden teszt után válthatnak (ahogy ezt gyakran a dojo-k kódolásakor teszik).

próbáld ki, és ne add fel, amikor akadályokkal szembesülsz, mivel sokan lesznek.

Test Driven Development (TDD): a Java példákat használó legjobb gyakorlatok jó kiindulópont. Annak ellenére, hogy Java példákat használ, ugyanaz, ha nem az összes gyakorlat alkalmazható bármely programozási nyelvre. Egy példa a Java (mint az előző esetben, ez könnyen aplicable más nyelveken) kérjük, vessen egy pillantást TDD példa Walkthrough cikket.

egy másik nagyszerű módja annak, hogy a tökéletesség TDD készségek kód katas (sok ezen az oldalon).

mi a tapasztalata a TDD-vel? Annyi variáció van, ahány csapat gyakorolja, és szeretném hallani a tapasztalatait.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.