Pliusai ir minusai apie bandomąją plėtrą

Kokie yra „Test Driven Development“ (TDD) privalumai ir trūkumai?

„Test Driven Development“ yra programinės įrangos kūrimo metodika, pagal kurią rašote ir paleisti testų rinkinys prieš rašant kodą.

Idėja yra ta, kad iš pradžių šie testai nepavyks ir tada pradėsite rašyti tiek kodo, kad bandytumėte išlaikyti visus testus. Visų testų išlaikymas gali būti atliktų kriterijų matas (atliktas-atliktas), taip pat padidėja pasitikėjimas kodo kokybe.


Be to, kaip ir bet kuri kita kūrimo metodika, yra keletas privalumų ir trūkumų, susijusių su TDD. Čia pateikiame keletą jų, tačiau prieš tai geriausia paaiškinti keletą punktų:

  • Atlikti vieneto testus nereiškia daryti TDD. Pirmąjį galite padaryti be antrojo. Tiesą sakant, jūs galite atlikti TDD be bandymų su vienetais (bet dauguma žmonių tai daro), šiuo atveju žmonės paprastai papildo bandymus su kitais bandymų skoniais. Jums tikrai reikia automatinio testavimo, kad ir kokie jie būtų.
  • Norėdami patikrinti kodą, galite atlikti TDD baltos dėžės testavimui. Bet jūs taip pat galite atlikti TDD juodosios dėžės bandymams, tai dažnai vadinama elgesiu paremta plėtra.

Tradiciškai procesas buvo koduoti daugybę modulių ir tada rašyti vieneto testus, kad būtų patvirtintas kodas. Tai pirmiausia kodas, bandymas vėliau. Bet jei užkodavus nėra laiko arba esate priverstas išleisti, tada visas vieneto testavimo pratimas praleidžiamas arba geriausiu atveju atliekamas atgaline data.


Dabar apie TDD privalumus ir trūkumus:



„Test Driven Development“ pliusai

  • Kadangi rašote mažus testus vienu metu, tai priverčia jūsų kodą būti moduliniu (kitaip prieš juos būtų sunku išbandyti). TDD padeda išmokti, suprasti ir įsisąmoninti pagrindinius gero modulinio dizaino principus.
  • TDD taip pat verčia gerą architektūrą. Kad jūsų kodą būtų galima patikrinti, jis turi būti tinkamai moduliuotas. Pirmiausia rašant testus, įvairios architektūrinės problemos dažniausiai iškyla anksčiau.
  • Dokumentuoja jūsų kodą geriau nei dokumentai (jis nepasenęs, nes jį nuolat naudojate).
  • Palengvina kodo priežiūrą ir pertvarkymą. TDD padeda užtikrinti aiškumą diegimo proceso metu ir suteikia apsauginį tinklą, kai norite pertvarkyti ką tik parašytą kodą.
  • Padaro bendradarbiavimą lengvesnį ir efektyvesnį, komandos nariai gali drąsiai redaguoti vieni kitų kodus, nes testai informuos juos, jei dėl pakeitimų kodas elgiasi netikėtai.
  • Kadangi TDD iš esmės verčia rašyti vieneto testus prieš rašant įgyvendinimo kodą, kodo atnaujinimas tampa lengvesnis ir greitesnis. Prieš dvejus metus parašytas pertvarkymo kodas yra sunku . Jei šis kodas yra pagrįstas gerų vieneto testų rinkiniu, procesas yra daug lengvesnis.
  • Padeda išvengti defektų - gerai, bent jau iš pradžių. TDD suteikia išankstinį įspėjimą dėl projektavimo problemų (kai jas lengviau išspręsti).
  • Padeda programuotojams iš tikrųjų suprasti savo kodą.
  • Sukuria automatizuotą regresijos testų rinkinį, iš esmės nemokamai. y. jums nereikia praleisti laiko po to, kai rašote vieneto testus, kad išbandytumėte įgyvendinimo kodą.
  • Tai skatina mažus žingsnius ir tobulina dizainą, nes tai leidžia jums sumažinti nereikalingas priklausomybes, kad būtų lengviau nustatyti.
  • Tai padeda išsiaiškinti reikalavimus, nes turite konkrečiai išsiaiškinti, kokius įnašus turite tiekti ir kokių rezultatų tikitės.
  • Vieneto testai yra ypač vertingi kaip saugos tinklas, kai reikia pakeisti kodą, kad būtų galima pridėti naujų funkcijų arba ištaisyti esamą klaidą. Kadangi techninė priežiūra sudaro nuo 60 iki 90% programinės įrangos gyvavimo ciklo, sunku pervertinti, kaip laikas, per kurį buvo sukurtas tinkamas vieneto testų rinkinys, gali atsipirkti per visą projekto gyvavimo laiką.
  • Testavimas rašant taip pat verčia stengtis, kad jūsų sąsajos būtų pakankamai švarios, kad būtų galima išbandyti. Kartais sunku įžvelgti to pranašumą, kol dirbate su kodu, kuriame jis nebuvo padarytas, o vienintelis būdas naudotis ir sutelkti dėmesį į tam tikrą kodo dalį yra paleisti visą sistemą ir nustatyti lūžio tašką .
  • „Kvailos“ klaidos užklumpa beveik iš karto. Tai padeda kūrėjams rasti klaidų, kurios sugaištų kiekvieno laiką, jei jos būtų rastos QA.


Testo varomos plėtros trūkumai

  • Turi būti išlaikytas pats testų rinkinys; testai gali būti ne visiškai deterministiniai (t. y. priklausomi nuo išorinių priklausomybių).
  • Testus gali būti sunku parašyti, ypač. už vieneto bandymo lygį.
  • Iš pradžių tai lėtina plėtrą; greitai pasikartojančioms paleisties aplinkoms įgyvendinimo kodas kurį laiką gali būti neparengtas dėl to, kad pirmiausia praleisite laiką rašydami testus. (Bet ilgainiui tai iš tikrųjų paspartina plėtrą)
  • Kaip ir bet kuris programavimas, yra didelis skirtumas tarp to, kaip tai padaryti, ir gerai. Gerų vieneto testų rašymas yra meno forma. Šis TDD aspektas dažnai nėra aptariamas, daugelis vadovų yra linkę sutelkti dėmesį į tokias metrikas kaip kodo aprėptis; tos metrikos nieko nepasako apie kokybė vieneto bandymų.
  • Vieneto testavimą turi nusipirkti visa komanda.
  • Iššūkis išmokti. Iš pradžių tai gali būti bauginanti ir nelengva išmokti visiems, ypač bandant išmokti patiems. Tai reikalauja daug atsidavimo (drausmės, praktikos, užsispyrimo) ir jūs turite turėti tikslą, kurį norite nuolat tobulinti.
  • Sunku pritaikyti esamam senam kodui.
  • Daugybė klaidingų supratimų, kurie neleidžia programuotojams to išmokti.
  • Sunku pradėti dirbti tokiu būdu. Ypač, jei daug metų dirbate kitu keliu.
  • Kartais tenka tyčiotis iš daugelio dalykų ar dalykų, kuriuos sunku pašiepti. Tai naudinga ilguoju laikotarpiu, bet šiuo metu skaudu.
  • Jūs turite nuolat tvarkyti namus. Rezervuojant vis daugiau ir daugiau bandymų, jūsų kūrimas tampa vis ilgesnis, todėl būtina juos patobulinti, kad jie būtų vykdomi greičiau, arba pašalinti nereikalingus testus.
  • Kaip ir bet kurią gerą techniką, vieneto bandymus galima atlikti iki kraštutinumų. Didžiausią naudą teikia vidutinės pastangos, kai testai visada naudoja kodą kuo paprasčiau. Jei pastebite, kad dažnai pertvarkote testus, yra didelė tikimybė, kad bandymų rinkiniui skiriate per daug laiko.
  • Tai gali būti lengva atitraukti dėl „pūkų“ ar išgalvotų funkcijų vieneto testavimo sistemoje. Turėtume prisiminti, kad paprasčiausi testai yra greičiausiai sukurti ir lengviausiai valdomi.
  • Nors tai yra absoliučiai būtina, nesėkmių testų kūrimas gali būti varginantis, tačiau galų gale tai atsiperka daug laiko.
  • Ankstyvosios stadijos refaktorizavimui reikalingos ir testavimo klasės.
  • Jei visi komandos nariai tinkamai neišlaiko savo testų, visa sistema gali greitai sugesti.