Kaip veikia testai arba TDD?

Sveiki,

Esu siek tiek naujas su TDD tai kolkas net pats principas man neaiskus. Man idomu kada testai isvis naudojami. Tarkime as parasau dideli gabala testu ir mano aplikacija visus testus proceedin'a tai sie testai runninami production aplikacijoje. Nejau jie visada susisuka startuojant koda? Ar tiesiog turite kazkoki staging serveri, kuriame sukasi testai, o production serveryje testu nei kvapo? Pasidalinkite kas savo patirtimi is day to day darbu su testais. Aciu.

Sveiki,

 

Esu siek tiek naujas su TDD tai kolkas net pats principas man neaiskus. Man idomu kada testai isvis naudojami. Tarkime as parasau dideli gabala testu ir mano aplikacija visus testus proceedin'a tai sie testai runninami production aplikacijoje. Nejau jie visada susisuka startuojant koda? Ar tiesiog turite kazkoki staging serveri, kuriame sukasi testai, o production serveryje testu nei kvapo? Pasidalinkite kas savo patirtimi is day to day darbu su testais. Aciu.

Testai yra projekte, bet niekas nesisuka naudojant prod. environment. Pasileidi kada nori, jie skirti kai developini, o ne, kad su jais vartotojas kažką darytų. Vartotojas turi gauti jau gerai parašytą kodą. Jie rašomi atskirai nuo site'o fileų, bet kaip minejau įeina į projekto direction'ą.

Galiu išskirti 3 jų grupes, kurios dažniausiai naudojamos.

Unit tests - Kai testuoji, koki metodą, pvz. ar jis teisingai atlieka skaičiavimą(ar toks rezultatas). Su php dažniausiai naudojamas PHPUnit. Tai čia TDD

Functional tests - Kai imituoji useri, kuris vaiksto po svetainę ir kažką daro. Atrodo vis dar TDD. Čia naudojamas pvz. Selenium.

Acceptance tests - Kaip ir pastarasis tik, kad parašo viską žmonių kalba(Taip, kad ir užsakovas suprastų). Čia jau BDD(behavior driven development). Naudojamas pvz. Behat.

Gaila, kad man niekas negalėjo paaiškint taip anksčiau :)

O patirtis su testais nedidelė, bet jos jau užtenka, kad galėčiau juos naudoti. Paprastai jie gelbsti po kodo pakeitimų, kai pakeiti kažką ir nepastebi, kad praleidai tą ir tą. Tuomet atomatiniai testai tau praneša, jog tu negauni reikiamo rezultato, pvz. kažkokiam puslapyje nepasileidžia kažkas.

Tam reikia laiko, bet tai atsiperka. Testus rašysi ne ką trumpiau, nei savo projekto funkcionalumą, bet juos reikia rašyti gerai, neatmestinai. Tuomet bus ir rezultatai.

Testai keliauja į production'ą, na bent jau pas mane.

Dažnai naudojami įvairūs tools'ai, kurie prasuka tau visus testus, kai juos keli į repozitoriją(pvz.: github'o). Sekmes :)

Sveiki,

 

Esu siek tiek naujas su TDD tai kolkas net pats principas man neaiskus. Man idomu kada testai isvis naudojami. Tarkime as parasau dideli gabala testu ir mano aplikacija visus testus proceedin'a tai sie testai runninami production aplikacijoje. Nejau jie visada susisuka startuojant koda? Ar tiesiog turite kazkoki staging serveri, kuriame sukasi testai, o production serveryje testu nei kvapo? Pasidalinkite kas savo patirtimi is day to day darbu su testais. Aciu.

Iš savo nedidelės dev patirties...

TDD'e testai naudojami nuolat. Programuojant - kas kelias ar keliolika minučių. TDD praktika tokia, kad programa pradedama rašyti nuo testo(ar kelių) rašymo. Testuojama vos tik pakeitus programos dalies kodą. Taupant laiką leidžiamas ne visas test suite, bet tik maža test suite dalis atsakinga už rašomos programos ypatybę (feature).

"Tarkime as parasau dideli gabala testu..."

Didelis gabalas testų rašomas nebent esamai programai, kurią reikia "padengti" testais, bet tai jau nėra TDD. Na nebent tai pasenęs(legacy) kodas, kuris ruošiamas "refactoringui", jis gerai dokumentuotas, lengvai skaitomas ir viskas taip aišku, kad galima rašyti testus visai programai, o tik po to refactorinti. Bet tai jau visai kita mokslinės fantastikos tema...

Kuriant naują programą rašomi keli testai, kurie tikrina vieną programos ypatybę(feature) ir kurių sąlygos nėra tenkinamos(raudoni testai). Tuomet kuriamas tos ypatybės kodas, kuris "praleidžia" testus(jie pasidaro žali). Vėliau kodas ir testai refactorinami. Jei viskas "žalia"(passing) - rašomi nauji testai naujam programos funkcionalumui.

Kas čia per spalvos?

Suprasti, ką reiškia programos kūrimas su TDD padeda Red-Green-Refactor ciklas, kuris yra lyg TDD pagrindas.

Manau bus aiškiau jei pateiksiu realią situaciją.

Kalkuliatoriaus programos kūrimas su TDD.

1.Parašomas testas sudėčiai apskaičiuoti.

Patikrinama, kad testas "nepraeina"(failing). RED stadija. Dažnai ir testo išvestis rodoma raudonai.

Parašomas kodas, kuris "praleidžia"(passing) testą. GREEN. Testo rezultatai žaliuoja.

Jei reikia - redaguojamas sudėties funkcijos kodas.Dinamas kodo readability(DRY, KISS). Pagalvojama apie kitų resursų panaudojimą, ateityje numatomus dalykus ir pan. Tai REFACTOR dalis.

Tikrinama ar testas vis dar passing. Jei fail - grįžtama prie kodo rašymo, kol passina.

2.Parašomas kodas skirtumui apskaičiuoti.

Patikrinama, kad skirtumo testas failina. RED

Parašomas kodas, kuris praleidžią skirtumo testą. GREEN

Jei reikia - patobulinamas skirtumo funkcijos kodas. REFACTOR

Patikrinama ar skirtumo kodo testai vis dar praleidžiami(passing).

3. Paleidžiami visi programos testai. Įsitikinama ar pastarasis kodas neįtakojo prieš tai parašyto.

Jei "žalia", einama prie sandaugos ir t.t.

Testavimo praktika

Priklausomai nuo programos ir developerio mėgiamos praktikos testai "leidžiami" įvairiai.

Vieniems patinka, kai funkcijos testas automatiškai prasisuka atnaujinus testo/kodo failą,

kiti mėgsta tokį variantą, kai testai paleidžiami jau užbaigus rašyti kodą. Pastaruoju atveju mažiau blaškomas dėmesys "nereikalinga" informacija ekrane.

Dažniausiu atveju programos ir testų kodas keliauja kartu.

Production serveryje įprastais atvejais testai neleidžiami. Testai leidžiami test(arba development) aplinkoje padarius kodo pakeitimą development'e, o prod'e kodas neturėtų keistis.

Išskirtiniais atvejais, kai kodo bazė labai didelė, taupomi developerių resursai(ar taupomas laikas) ir leidžia biudžetas - testai leidžiami cloude arba dedikuotame su rimtu hw, ramfs vietoje ssd ir pan.