Testų varoma plėtra
Test Driven Development (TDD) yra programinės įrangos kūrimo metodas, kai bandomieji atvejai yra kuriami siekiant nurodyti ir patvirtinti, ką veiks kodas. Paprasčiau tariant, pirmiausia sukuriami ir išbandomi kiekvienos funkcijos testavimo atvejai, o jei bandymas nepavyksta, naujas kodas parašomas siekiant išlaikyti testą ir padaryti kodą paprastą ir be klaidų.
„Test-Driven Development“ prasideda suprojektuojant ir tobulinant kiekvienos mažos programos funkcijos testus. TDD nurodo kūrėjams rašyti naują kodą tik tuo atveju, jei nepavyko automatizuoto testavimo. Taip išvengsite kodo dubliavimo. Visa TDD forma yra bandymu pagrįstas kūrimas.
Paprasta TDD samprata yra parašyti ir ištaisyti nepavykusius testus prieš rašant naują kodą (prieš kūrimą). Tai padeda išvengti kodo dubliavimo, nes vienu metu rašome nedidelį kodo kiekį, kad išlaikytume testus. (Testai yra ne kas kita, o reikalavimo sąlygos, kurias turime išbandyti, kad jas įvykdytume).
„Test-Driven“ plėtra yra automatizuoto testavimo kūrimo ir vykdymo procesas prieš faktinį programos kūrimą. Taigi, TDD kartais dar vadinama „ Test First Development“.
Šioje pamokoje sužinosite daugiau apie
- Kaip atlikti TDD testą
- TDD vs. Tradicinis testavimas
- Kas yra priėmimo TDD ir „Developer TDD“
- TDD mastelio keitimas naudojant „Agile Model Driven Development“ (AMDD)
- Bandomoji plėtra (TDD), palyginti su „Agile Model Driven Development“ (AMDD)
- TDD pavyzdys
- TDD nauda
Kaip atlikti TDD testą
Atlikdami šiuos veiksmus apibrėžkite, kaip atlikti TDD testą,
- Pridėkite testą.
- Atlikite visus bandymus ir patikrinkite, ar nepavyksta atlikti kokio nors naujo bandymo.
- Parašykite kodą.
- Atlikite testus ir refaktoriaus kodą.
- Pakartokite.
TDD ciklas apibrėžia
- Parašykite testą
- Priverskite jį paleisti.
- Pakeiskite kodą, kad jis būtų teisingas, ty Refactor.
- Pakartokite procesą.
Keletas paaiškinimų apie TDD:
- TDD nėra nei apie „testavimą“, nei apie „dizainą“.
- TDD nereiškia „parašyti kai kuriuos testus, tada sukurti sistemą, kuri išlaikys testus.
- TDD nereiškia „atlikti daug bandymų“.
TDD vs. Tradicinis testavimas
TDD metodas pirmiausia yra specifikacijos technika. Tai užtikrina, kad jūsų šaltinio kodas bus kruopščiai patikrintas patvirtinimo lygiu.
- Atliekant tradicinius bandymus, sėkmingas testas nustato vieną ar daugiau defektų. Tai tas pats, kas TDD. Kai bandymas nepavyksta, jūs padarėte pažangą, nes žinote, kad turite išspręsti problemą.
- TDD užtikrina, kad jūsų sistema iš tikrųjų atitinka jai nustatytus reikalavimus. Tai padeda sustiprinti pasitikėjimą savo sistema.
- TDD daugiau dėmesio skiriama gamybos kodui, kuris patikrina, ar bandymai veiks tinkamai. Tradicinių bandymų metu daugiau dėmesio skiriama bandomųjų atvejų projektavimui. Ar bandymas parodys tinkamą / netinkamą programos vykdymą, kad būtų įvykdyti reikalavimai.
- TDD pasiekiate 100% aprėpties testą. Testuojama kiekviena kodo eilutė, skirtingai nei tradiciniai.
- Tiek tradicinio testavimo, tiek TDD derinys lemia sistemos testavimo, o ne sistemos tobulinimo svarbą.
- „Agile Modeling“ (AM) srityje turėtumėte „išbandyti su tikslu“. Turėtumėte žinoti, kodėl ką nors bandote ir kokį lygį reikia išbandyti.
Kas yra priėmimo TDD ir „Developer TDD“
Yra du TDD lygiai
- Priėmimo TDD (ATDD): Su ATDD jūs rašote vieną priėmimo testą. Šis bandymas atitinka specifikacijos reikalavimus arba sistemos elgesį. Po to parašykite tik tiek gamybos / funkcionalumo kodo, kad įvykdytumėte priėmimo testą. Priėmimo testas orientuotas į bendrą sistemos elgesį. ATDD taip pat buvo žinomas kaip elgesio skatinamas vystymasis (BDD).
- Kūrėjo TDD: Su „Developer TDD“ rašote vieną kūrėjo testą, ty vieneto testą, tada pakanka tik tiek gamybos kodo, kad įvykdytumėte šį testą. Vieneto bandymas sutelkia dėmesį į kiekvieną mažą sistemos funkcionalumą. Kūrėjo TDD paprasčiausiai vadinamas TDD.
Pagrindinis „ATDD“ ir „TDD“ tikslas - tiksliai ir tiksliai (JIT) nurodyti išsamius, vykdomus jūsų sprendimo reikalavimus. JIT reiškia atsižvelgti tik į tuos reikalavimus, kurie reikalingi sistemoje. Taigi padidinkite efektyvumą.
TDD mastelio keitimas naudojant „Agile Model Driven Development“ (AMDD)
TDD yra labai gerai išsami specifikacija ir patvirtinimas. Nepavyksta apgalvoti didesnių klausimų, tokių kaip bendras dizainas, sistemos naudojimas ar vartotojo sąsaja. AMDD sprendžia Agile mastelio problemas, kurių TDD nėra.
Taigi AMDD buvo naudojama didesniems klausimams spręsti.
AMDD gyvavimo ciklas.
„Model-driven Development“ (MDD), prieš rašant šaltinio kodą, sukuriami išsamūs modeliai. Kuris savo ruožtu turi judrų požiūrį?
Aukščiau pateiktame paveikslėlyje kiekvienas langelis reiškia kūrimo veiklą.
Įsivaizdavimas yra vienas iš TDD procesų numatymo / įsivaizdavimo proceso, kuris bus atliekamas per pirmąją projekto savaitę. Pagrindinis įsivaizdavimo tikslas yra nustatyti sistemos apimtį ir sistemos architektūrą. Norint sėkmingai įsivaizduoti, atliekami aukšto lygio reikalavimai ir architektūros modeliavimas.
Tai procesas, kurio metu nėra atliekama išsami programinės įrangos / sistemos specifikacija, o programinės įrangos / sistemos reikalavimų nagrinėjimas apibrėžia bendrą projekto strategiją.
- 0 kartojimas: įsivaizdavimas
Yra du pagrindiniai subaktyvinimai.
- Pradinių reikalavimų numatymas.
Gali praeiti kelios dienos, kol bus nustatyti aukšto lygio reikalavimai ir sistemos taikymo sritis. Pagrindinis dėmesys skiriamas naudojimo modelio, pradinio domeno modelio ir vartotojo sąsajos modelio (NS) tyrimui.
- Pradinis architektūrinis įsivaizdavimas.
Sistemos architektūrai identifikuoti taip pat reikia kelių dienų. Tai leidžia nustatyti technines projekto kryptis. Pagrindinis dėmesys skiriamas technologinių diagramų, vartotojo sąsajos (UI) srauto, domenų modelių ir keitimo atvejų tyrinėjimui.
- Iteracijų modeliavimas:
Čia komanda turi suplanuoti darbą, kuris bus atliekamas kiekvienoje iteracijoje.
- Kiekvienai iteracijai naudojamas judrus procesas, ty kiekvienos iteracijos metu prioritetas bus pridėtas naujas darbo elementas.
- Bus atsižvelgta į pirmąjį prioritetinį darbą. Pridėtos darbo prekės gali būti pakeistos prioritetais arba pašalintos iš daiktų kamino bet kuriuo metu.
- Komanda aptaria, kaip jie ketina įgyvendinti kiekvieną reikalavimą. Tam naudojamas modeliavimas.
- Kiekvieno reikalavimo, kuris bus įgyvendinamas tam iteravimui, analizė ir projektavimas atliekami.
- Modelis šturmuoja:
Tai taip pat vadinama modeliu „Tiesiog laiku“.
- Čia modeliavimo sesijoje dalyvauja 2/3 narių komanda, kuri aptaria klausimus popieriuje ar lentoje.
- Vienas komandos narys paprašys kito modelio su jais. Šis modeliavimo užsiėmimas užtruks maždaug nuo 5 iki 10 minučių. Kur komandos nariai susirenka dalytis lenta / popieriumi.
- Jie nagrinėja problemas, kol neranda pagrindinės problemos priežasties. Laiku, jei vienas komandos narys nustato problemą, kurią nori išspręsti, jis / ji greitai priims pagalbą kitiems komandos nariams.
- Tuomet kiti grupės nariai tyrinėja šią problemą ir visi tęsia toliau kaip anksčiau. Tai taip pat vadinama stand-up modeliavimu arba klientų QA sesijomis.
- Bandomoji plėtra (TDD).
- Tai skatina patvirtinti jūsų paraiškos kodą ir išsamią specifikaciją.
- Tiek priėmimo testas (išsamūs reikalavimai), tiek kūrėjo testai (vieneto testas) yra TDD įvestis.
- TDD daro kodą paprastesnį ir aiškesnį. Tai leidžia kūrėjui išlaikyti mažiau dokumentų.
- Atsiliepimai.
- Tai neprivaloma. Tai apima kodų patikrinimus ir modelių peržiūras.
- Tai galima padaryti kiekvienam kartojimui arba visam projektui.
- Tai yra gera galimybė pateikti atsiliepimus apie projektą.
Bandomoji plėtra (TDD), palyginti su „Agile Model Driven Development“ (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
TDD pavyzdys
Šiame pavyzdyje mes apibrėžsime klasės slaptažodį. Šioje klasėje mes stengsimės patenkinti šias sąlygas.
Slaptažodžio priėmimo sąlyga:
- Slaptažodis turi būti nuo 5 iki 10 simbolių.
Pirmiausia parašome kodą, kuris atitinka visus aukščiau nurodytus reikalavimus.
1 scenarijus : norėdami paleisti testą, mes sukuriame klasę „PasswordValidator“ ();
Mes paleisime virš klasės TestPassword ();
Išvestis perduodama, kaip parodyta žemiau;
Išvestis :
2 scenarijus : Čia matome TestPasswordLength () metodą, nereikia kurti klasės „PasswordValidator“ egzemplioriaus. Egzempliorius reiškia sukurti klasės objektą, nurodantį tos klasės narius (kintamuosius / metodus).
Mes pašalinsime klasę „PasswordValidator pv = new PasswordValidator ()“ iš kodo. IsValid () metodą galime iškviesti tiesiogiai naudodami „ PasswordValidator“. „IsValid“ („Abc123“) . (Žr. Paveikslėlį žemiau)
Taigi mes refaktorius (pakeisti kodą), kaip nurodyta toliau:
3 scenarijus : pertvarkius išvestį rodoma nepavykusi būsena (žr. Paveikslėlį žemiau), nes mes pašalinome egzempliorių. Taigi nėra nuorodos į netistatinį metodą isValid ().
Taigi turime pakeisti šį metodą įtraukdami „statinis“ žodį prieš Boolean, nes viešasis statinis loginis yra „IsValid“ (eilutės slaptažodis). Pertvarkyti „Class PasswordValidator“ (), kad pašalintumėte anksčiau pateiktą klaidą, kad išlaikytumėte testą.
Išvestis:
Atlikę bandymą „PassValidator“ () klasėje, jei atliksime testą, išvestis bus perduota, kaip parodyta žemiau.
TDD pranašumai
- Ankstyvas pranešimas apie klaidą.
Kūrėjai išbando savo kodą, tačiau duomenų bazių pasaulyje tai dažnai susideda iš rankinių testų arba vienkartinių scenarijų. Naudodamiesi TDD, laikui bėgant sukursite automatinių testų rinkinį, kurį jūs ir bet kuris kitas kūrėjas galite iš naujo paleisti savo nuožiūra.
- Geriau suprojektuotas, švaresnis ir išplėstinis kodas.
- Tai padeda suprasti, kaip kodas bus naudojamas ir kaip jis sąveikauja su kitais moduliais.
- Tai lemia geresnį dizaino sprendimą ir labiau prižiūrimą kodą.
- TDD leidžia rašyti mažesnį kodą su viena atsakomybe, o ne monolitines procedūras su daugybe atsakomybių. Tai leidžia lengviau suprasti kodą.
- TDD taip pat verčia rašyti tik gamybos kodą, kad išlaikytų testus pagal vartotojo reikalavimus.
- Pasitikėjimas refaktoriumi
- Jei pakeisite kodą, kode gali būti pertraukų. Taigi turėdami automatinių testų rinkinį, galite ištaisyti šias pertraukas prieš išleidimą. Tinkamas įspėjimas bus pateiktas, jei bus nustatyta pertraukų, kai naudojami automatiniai bandymai.
- Naudojant TDD, turėtų būti gaunamas greitesnis ir išplėstinis kodas su mažiau klaidų, kurias galima atnaujinti su minimalia rizika.
- Gerai komandiniam darbui
Jei nėra nė vieno komandos nario, kiti komandos nariai gali lengvai pasiimti ir dirbti su kodu. Tai taip pat padeda dalytis žiniomis, taip padarant komandą efektyvesnę.
- Naudinga kūrėjams
Nors kūrėjams tenka skirti daugiau laiko rašant TDD bandomuosius atvejus, derinimui ir naujų funkcijų kūrimui reikia daug mažiau laiko. Parašysite švaresnį, mažiau sudėtingą kodą.
Santrauka:
- TDD reiškia bandymu pagrįstą plėtrą. Tai yra kodo modifikavimo procesas, kad būtų išlaikytas anksčiau sukurtas testas.
- Tai labiau akcentuoja gamybos kodą, o ne bandomojo atvejo dizainą.
- Testais pagrįstas kūrimas yra kodo modifikavimo procesas, kad būtų išlaikytas anksčiau sukurtas testas.
- Programinės įrangos inžinerijoje tai kartais vadinama „Test First Development“.
- TDD apima kodo pertvarkymą, ty tam tikro kodo kiekio pakeitimą / pridėjimą prie esamo kodo, nedarant įtakos kodo elgsenai.
- Naudojant TDD, kodas tampa aiškesnis ir lengvai suprantamas.
Prie šio straipsnio prisidėjo Kanchanas Kulkarni