TDD: How implement it?

TDD-г хэзээ яаж ашиглах вэ?

Өмнөх цуврал дээр TDD-н талаар хэт нэг (зөвхөн сайн) талыг барьсан зүйл бичжээ. Зарим нэг хүмүүсээс сул тал байна уу? Хэзээ ашиглах ёстой юм бэ? гэсэн асуулт ирлээ. Тийм болохоор энэ удаад зөвхөн сул талыг бариад аль болох TDD-г няцаагч, үл дэмжигчийн байр сууринаас бичих гээд үзье.

TDD-г үл дэмжигч Үлмэдэх (ҮМ), TDD-г дэмжигч Ихмэдэх (ИМ) 2-н харилцан яриа.

ҮМ: Эхлээд тест код бичээд дараа нь жинхэнэ кодоо бичинэ гэхээр нэг л төсөөлөгдөхгүй, утгагүй санагдах юм. Ялангуяа огт бичээгүй байгаа программын тест кодыг бичээд, тест кодыг ажилуулахаар мэдээж л compile error гараад зогсчихно биз дээ?

ИМ: Тэр чинь энэ аргын гол амин сүнс нь юм шүү дээ. Алхам тутамдаа тайлж ойлгохын аргагүй асуудалтай тулгарсанаас мэдээжийн амархан асуудалтай тулгараад шийдээд явах нь амар биз дээ. Ачаа багатай бол ууланд авирахад хялбар юм даа.

ҮМ: Гэхдээ л байнга test code бичих, fake, refactoring хийх төвөгтэй. Харин ч илүү ачаалал болох биш үү?

ИМ: Энэ аргын гол үндэс нь аль болох теслтэгдээгүй код үлдээхгүй гэдэгт байгаа юм. Тиймээс мартахаасаа өмнө тест кодоо бичих ёстой юм. Дараад нь тест кодыг нөхөөд бичиж болох авч тест хамралт (test coverage) өндөртэй болж чадах уу?

ҮМ: Чанартай код гаргаж авахын тулд эхлээд тест код бичихийг ойлголоо. Гэхдээ fake, refactoring талаархи миний асуултанд та хариулсангүй.

ИМ: Өө, тийм. Fake, refactoring гэдэг нь нөгөө л ачаа (овоорсон бөөн асуудал, стресс) хөнгөн явах гэдэг л санаа яваад байгаа. Ачаагаа хөнгөн байлгахын тулд fake, refactoring хийдэг юм. Гэхдээ хэтрүүлбэл илүү ачаа болж магадгүй л дээ. Тэр зохистой харьцааг хийж үзэхээс нааш мэдэхгүй болов уу.

ҮМ: Ачаагаа хөнгөн байлгах, овоорсон бөөн асуудал, стресс гэдгийг нэг л сайн ойлгохгүй байна.

ИМ: За, чи программд 10 өөрчлөлт хийх ёстой байжээ. Тэр бүх өөрчлөлтийг нэг дор хийчээд дараад нь тестлэжээ. Тэгсэн алдаа илэрлээ. Тэгэхээр программын хаа нэгтээ хийсэн 10 өөрчлөлтийн дундаас алдааг хайх хэрэгтэй биз? Энэ тохиолдолд чиний ачаа 10-тай тэнцүү. Хэрэв чи энэ бүх өөрчлөлтийг нэг нэгээр системтэй хийгээд явбал хамгийн сүүлд хийсэн өөрчлөлтөөс боллоо гэдгийг төвөггүйхэн ойлгоно. Энэ тохиолдолд чиний ачаа хэд байх уу?

ҮМ: Нэг.

ИМ: Зүйтэй. Арав дахин бага байна шүү дээ! Энэ чинь нөгөө ачаа, овоорсон бөөн асуудал, стресс гээд байгаа чинь. Ачаа багатай бол хөнгөн шаламгай хөдөлнө. Том асуудлыг жижиг асуудалд хувааж, testing-coding cycle-г богинохон болгохоор алдааг эрт илрүүлэх, өндөр бүтээмжтэй болж байгаа юм.

ҮМ: Яагаад гэдгийг ч яахав ойлголоо л доо. Гэхдээ долоо хоног кодлох ёстой байтал тест код бас бичнэ гэхээр 2 долоо хоног болчих юм биш үү.

ИМ: Өнгөцхөн бодвол чиний хэлж байгаа үнэн. Кодлох гэдгийг (үндсэн код + тест код)-г кодлох явдал гээд ойлгочихвол арай өөр болно. Өөрөөр хэлбэл кодлох, тестлэх ажиллагааг хамтад нь хийнэ гээд тохирчихвол. Тэртэй тэргүй төлөвлөгөө гаргахдаа кодлох, тестлэх үе шатанд зориулж цаг гаргадаг шүү дээ. Энэ 2 үе шатыг хамтад нь томоор харвал нийтдээ зарцуулах хугацаа адилхан, харин ч богинохон гарч магадгүй л юм.

ҮМ: Аанхаан. Харин ээ, менежер ойлгох байгаа?

ИМ: Ммм, танай менежерт, чанар чухал уу? Алдаатай ч байсан хамаагүй, ямар ч байсан хурдан release хийх нь чухал уу? гэдгээс хамаарах юм болов уу? Гэхдээ уламжлалт аргаар хийсэнтэй дор хаяж адил хугацаа зарж чадаж байвал ч юм хэлэхгүй болов уу.

ҮМ: Тест код бичихгүй бол хурдан дуусах юм биш үү? Заавал тест код бичилгүйгээр тестлэж болно биз дээ? Зарим газар тестер гэж тусгай үүрэгтэй хүн байдаг.

ИМ: Тестийг ганцхан удаа хийгээд болчино, дахиад хэзээ ч тэр тестийг давтаж хийх шаардлагагүй гэсэн батлагаа байвал, эсвэл тухайн тохиолдол гараар тестлэх нь илүү үр дүнтэй, найдвартай, хурдан байвал тест код бичилгүйгээр тестлэж болох л юм. Ихэнхи тохиолдолд тестийг нэг бус удаа хийдэг.

Regression test, Degradation test хийж байсан биз дээ. Тестийг олон удаа яг нэг хэвээр, алдаа мадаггүй, тест кодоос илүү хурдан хийж чадна гэвэл болно. Гэхдээ заавал хүний оролцоо шаардлагатай Acceptance test г.м-н хувьд асуудал тусдаа.

Тестерийн хувьд олон хүнтэй багийн хувьд тохиромжтой юм. Мэргэшсэн тестер байгаад программ бичсэн хүнээс тусдаа хүн хөндлөнгөөс шалгах нь сайн талтай ч тухайн тестлэх гэж буй хэсгийн цаад бизнес шаардлагыг зөв ойлгосон байх шаардлагатай. Иймээс зохиомжлогч, хөгжүүлэгч, чанар шалгагчийн хооронд ойлголтын зөрүү гаргахгүй байх тал дээр сайн анхаарахгүй бол болохгүй. Яг энэ шалтгаанаар XP-чүүд тухайн хэсгийг хамгийн сайн мэдэх хүн (голцуу хөгжүүлэгч өөрөө) тестлэхийг эрхэмлэдэг.

Тест код бичих талаар нэмж хэлэхэд XP-чүүд автоматжуулсан тест гэж их ярьдаг. Байнга давтагддаг тестлэх үйл ажиллагааг хүний хүчин зүйлээс хамааралгүй болгох, түүнийг автоматжуулах гэсэн үг юм.

Системийн алдаа доголдлыг эрт илрүүлж, асуудлыг томрохоос өмнө шийдвэрлэх, төлөвлөсөн цаг хугацаандаа бүтээгдэхүүнийг хүлээлгэн өгөхийн тулд continues integration (нэгтгэсэн тестийг аль болох эрт эхлүүлж, нэгтгэсэн тестийг тасралтгүй хийж байх) хийх ёстой гэж итгэдэг. Үүний тул тестийг автоматжуулах, тестийг автоматжуулахын тулд тест код бичих хэрэгтэй болдог юм.

ҮМ: Түрүүн голцуу хөгжүүлэгч өөрөө тестлэдэг гэлээ. Тэгэхээр чинь өөрөө өөрийнхөө алдааг яаж олох юм болж байна?

ИМ: Зүйтэй. Сайхан асуулт байна. Тэрний тулд source code review, test code review хийдэг. XP-д шалгарсан нэг арга бий. Pair programming (PP) буюу хосоор программчлах гэж. PP гэснээс TDD-г PP-тэй хослуулж ашиглавал маш үр дүнтэй.　Энэ талаар дараа тухтай ярилцъя.

ҮМ: Тест их л бичих болох нь дээ. Эхэндээ бичиж суртлаа хугацаа их алдах байх даа?

ИМ: Дасч, дадлагажих хүртэл хугацаа хэрэгтэй. Аажим аажмаар хийх хэрэгтэй болов уу?

Миний хувьд 100% TDD ашигладаггүй, холимог байдлаар хийдэг. Яаж хийх нь сайн төсөөлөгдөж байгаа хэсэг, голцуу интерфейсийн хувьд хөдөлгөөн орохооргүй газруудын хувьд хийх нь зүйтэй гэж боддог. Бусад модулиас дуудагдах (харагдах) public (exposed-公開された) function-н хувьд эхлэж тест код бичээд хийгээд явбал зүгээр. Private function өөрчлөгдөх магадлал өндөр тул өөрчлөгдөх болгонд test first, fake, refactoring хийх нь хэт ачаалал өгнө. Урьдчилж харагдахгүй байгаа, хялбархан хийж болохооргүй хэсгийг эхлэж үндсэн кодоо бичээд, дараа нь тест код бичээд шалгадаг. Гол нь тестлэх, кодлох 2-н хоорондох зайг ойрхон байлгахыг эрхэмлэдэг. Хүн хүнээс хамаараад таашаал өөр болохоор өөртөө таарсан тэр зохистой хувилбарыг олох ёстой юм уу даа.

Энд нэг зүйлийг дурдахгүй бол болохгүй. Асуудлыг хамгийн энгийнээр, давтагдахгүйгээр шийдэх гэсэн санааг марталгүй хэрэгжүүлээд явбал хэрэгжүүлэхэд тийм ч хэцүү асуудал биш.

ҮМ: Тэгээд энэ аргыг хэр өргөн хэрэглэдэг юм?

ИМ: Ммм, надад бэлэн хэлчих тоо баримт алга. Хэрэв итгээд зөв хэрэгжүүлээд явбал гарцаа байхгүй маш үр дүнтэй арга. Сүүлийн үед цаг үеийн шаардлагаар тэр үү? Үнэхээр дэвшилттэй арга болоод тэр үү? Agilist-ууд улам олон болж байгаа. Аль аль нь л байх. Үүнийг дагаад TDD ч гэсэн улам олон дэмжигчтэй болж байгаа гэж боддог шүү!

ҮМ: Багийн бусад гишүүд дэмжихгүй бол яах уу?

ИМ: Өмнөх компанид намайг ойлгож дэмжих хүн байгаагүй ч гэсэн ганч дайчин ганцаардахгүй гээд ганцаараа хийгээд л болоод байдаг байсан. Гол нь итгэл үнэмшил байгаад хийх хүсэл эрмэлзэл байвал бусдаас хамаараад байх зүйл биш юм.

ҮМ: Тэгвэл ямар үед хэрэглэвэл зүгээр үү?

ИМ: Хүний амь нас, эрүүл мэнд, мөнгөтэй холбоотой тестлэх нь гол зорилго болсон төсөлд энэ арга их тохиромжтой болов уу. Хамгийн гол нь итгэл үнэмшилтэй, яагаад ингэж хийх гэж байгаагаа сайтар ойлгож, хүлээн зөвшөөрөөд, өөрийн багт тохирох жорыг гаргаж чадвал ямар ч төсөл байсан үр дүнд хүрнэ гэж л хэлэх байна даа. Хэрэгжүүлэхэд гол саад болох зүйл багийн гишүүдийн сэтгэл зүй бэлэн байх, тухайн баг үнэхээр кодлох дуртай хүмүүсээс бүрдсэн үү? Хэр чадвартай хүмүүс цугласан бэ гэдгээ ихээхэн хамаарах байх. Гол нь ингэж хөгжүүлэхийн цаад утга учир, мөн чанарыг ойлгоод, аливаа асуудалд хандах хандлага нь зөв бол заавал чадварлаг хүмүүс байх шаардлагагүй. Хүнийг хөгжүүлж, чадваржуулж болно. За, ингээд яриагаа дуусгах уу?

ҮМ: 3а тэгье. Цаг ч нэлээн явчиж. Гайгүй сайн ойлголттой боллоо. Танд их баярлалаа.

ИМ: Зүгээр ээ.

ҮМ: Дараа асуух зүйл гарвал, асууна шүү!

ИМ: 3а, тэгээрэй. Зав байгаад, миний хүчрэх зүйл байвал ...

За, нэг иймэрхүү. Эндээс TDD-н талаар жаахан ч гэсэн ойлголт авсан байх гэж бодож байна. Одоо жинхэнээсээ миний мэддэг TDD дууслаа. Дараа уулзатлаа, түр баяртай.