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“.
![Schema](https://images.delfi.lt/media-api-image-cropper/v1/5bdaf120-7e1d-11ed-a628-f15cb6709fa2.jpg?noup&w=400)
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
![Schema](https://images.delfi.lt/media-api-image-cropper/v1/5be921f0-7e1d-11ed-ab81-a71b60a80a19.jpg?noup&w=400)
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“.