Technologas: kam programuotojams reikalingi tie testai?

Neseniai gavau tokį klausimą – o kam programuotojams reikia rašyti testus? Man tarsi viskas akivaizdu ir paprasta, bet sekundei išmušė iš vėžių. Žinoma, galima programinę įrangą kurti ir be jų – kodą leisti tiesiai į gyvenimą. Gali net būti, kad pasiseks ir jis veiks puikiai.

Bet sugalvojau šiems laikams aktualią analogiją: Ką darome kai norime įsitikinti, kad vaistai kuriuos kuriame, neturi nežinomų šalutinių poveikių? Atliekame bandymus. Lygiai tas pats ir programavime. Užtikriname, kad kodas būtų įskaitomas, švarus ir, svarbiausia, toliau vystomas, o ne išbraukiamas kaip prašantis „refaktorinimo“.

Testavimo rūšys yra kelios, bet viena dažniausiai sutinkamų – unit testai, kai testuojamos smulkios kodo dalys: klasės, metodai ir funkcijos. Savo galvoje suradau 6 pagrindines priežastis, kodėl jų verta imtis kiekvienam geram programuotojui, kad visiems gyvenimas taptų lengvesnis.

1. Disciplina ir griežtumas

Ilgai galvojau, kokį argumentą dėti kaip pirmą, bet po to nutariau pažvelgti į save iš šono ir nuspręsti – iš kur kyla ta tikroji testų nauda? Supratau, kad kiekvienas programuotojas nori, kad visi įrankiai, kuriais naudojasi darbe, būtų griežti ir tikslūs. Kitaip – toks tu ir programuotojas.

Ir kaip tą tikslų griežtumą užtikrinti? Be gerųjų praktikų ir testų nelabai kas lieka. Mano atveju, čia suveikia tik griežtumas parašyti kodą, kuris bus testuojamas. O priešingu atveju (o tokių tikrai buvo), jaučiuosi rašąs jau iš karto pasenusį kodą.

2. Kokybė ir ilgaamžiškumas

Įsivaizduokime situaciją, kad nueini pas stomatologą ir jis sako: „Nori, kad pataisyčiau dantis kokybiškai, bet sugaiščiau šiek tiek daugiau laiko, ar kad padaryčiau greitai, kainuotų nedaug, bet po to tektų ateiti pas mane kur kas dažniau?“ Atsakymas turbūt aiškus kaip diena. Visgi, kažkodėl, kai tai liečia ne savijautą, o darbinius klausimus, mąstymo modelis dažnai pasikeičia. Bet esmė juk lieka ta pati – kokybiškai atliktas darbas šiandien lemia ilgalaikę sėkmę ir ramesnę galvą ateityje.

3. Neefektyvus legacy kodas

Žinoma, nedėčiau lygybės tarp kodo (ne)padengimo testais ir „legacy“ apibrėžimo. Aišku, kad įmanoma parašyti ir neefektyvų legacy kodą padengtą testais. Lygiai taip pat įmanoma parašyti ir labai gerą kodą, kuris testais dengtas nėra. Bet čia kalbame apie kraštutinumus. Veikiausiai esu parašęs gero kodo ir be testų, bet lygiai tas pats galioja ir kodui, į kurį pasižiūrėjęs kitas susimastys: „Ką anas čia darė?“. Bet kokiu atveju, gero kodo nereikia refactorinti (nebent pasikeitė reikalavimai), o štai blogą – reikia. Ir kai jis neturi padengimo testais, tada prasideda ašaros.

4. Antras kartas

Ar egzistuoja programuotojas, kuris po savaitės pažiūrėjęs į savo parašytą kodą nebūtų pagalvojęs: „Kodėl priėmiau tokį keistą sprendimą? Gi galėjau pasinaudoti bibliotekomis, surasti daug geresnį sprendimą arba perpanaudoti jau egzistuojančias klases.“ Kai pradėjau rašyti testus, šitas momentas galvoje pasidarė daug dažnesnis.

Tuo pačiu pagaudavau papildomų naudų – kaip, pavyzdžiui, elgsis mano kodas, jei paduosiu netaisyklingai suformuluotą inputą? Arba dar netikėtesnis variantas – o ką, jei paduosiu atsitiktinį skaičių (monkey testing)?

5. Atrandamos netikėtos klaidos

Kodas padengtas testais yra geresnis nei nepadengtas. Skamba akivaizdžiai, bet bėgant laikui, kai pradedamas naujas funkcionalumas ir iškyla maža klaida, programuotojai iš karto žino jos priežastį, todėl nereikia ieškoti sprendimo per visą kodo bazę. Unit testai padeda programuotojams greitai identifikuoti problemas ir dar greičiau jas išspręsti.

6. Testai ruošia dokumentaciją

Tiesa, dokumentaciją ne vartotojams, ne administratoriams, o patiems programuotojams.

Įsivaizduokime realią situaciją, kuri yra nutikusi kiekvienam dirbančiam su kodu. Įprastai, norint nieko nesulaužyti, reikia praeiti tokį ciklą: parašai veikiantį kodą ir tada, kad įsitikintum, jog tikrai niekas nelūžo, praleidi testus per visą projektą. Bet jeigu užmiršai arba atsitraukei nuo projekto, atėjęs naujas kolega ras neveikiančius testus. Ir ką jis darys? Žinoma, kad pataisys. Arba ne. Arba jis leis sau galvoti, kad tie testai jau seniai neveikia ir pradės nežiūrėti į juos. Ir tada prasideda problemos. Šitam rebusui išspręsti, dažniausiai naudojami CI (continuous integration) servisai, kurie praleidžia testus po pakeitimo.

Bet gi nėra kada testuoti!

Pabaigai pasilikau svarbiausią dalį. Labai dažnai kalbėdamas su įvairaus plauko žmonėmis, išgirstu tokius žodžius: „taip taip, sutinku, testų reikėtų, bet pas mus labai didelis tempas ir jų rašyti tiesiog nespėjam“.

Pasakysiu tiesiai – man atrodo, kad čia yra didžiulis melas, kurį sugalvojo programuotojai, kurie tingi arba nenori (nes dirba su didžiulėmis legacy sistemomis). Nesupraskite klaidingai, ir save priskiriu prie jų, esu ne kartą pasakęs panašų sakinį. Bet jeigu nori, visada rasi laiko/žinių. Belieka tik panorėti.

Su vienu kolega diskutuodami apie rašymą sutarėme, kad straipsnio parengimas visuomet atrodo kaip begalinis darbas, bet visi ledai ima judėti tik tuomet, kai prisėdi prie balto lapo ir parašai pirmą sakinį. Tad jeigu nors vieną iš skaitančių užkrėčiau parašyti testą savo kodui – mano misija pavyko.

Vaidas Mikalauskas yra „Adeo Web“ technologijų vadovas. Daugiau autoriaus darbų yra socialiniame tinkle „LinkedIn“.