Тестээр хөтлөгдөх хөгжүүлэлт
Test driven development
Тестээр хөтлөгдөх/жолоодогдох/зохицуулагдах хөгжүүлэлт гэдэг маань нэрнээс нь харвал тест дээр тулгуурлаж явагддаг арга болох нь. Agile хөгжүүлэлийн үед хэрэглэгддэг шалгарсан туршлагуудын нэг юм. Хөгжүүлэлт дараалсан маягаар явагдана.
Ажлын урсгалын дараалал нь:
1. Тест бичнэ. Энэ нь шинэ тестийг тодорхойлно гэсэн үг. Бичнэ гэдэг нь тухайн тестийг шалгах код ч юмуу скрипт ч юмуу ямар нэг зүйл бий болно гэдгийг илэрхийлж байгаа юм. Хэрэв бичих тест байхгүй бол код маань бүх шаардлагыг хангасан гэсэн үг.
2. Тестүүдийг ажиллуулж үзнэ. Бүх тестүүдийг ажиллуулж аль тестийг давж чадахгүй байгааг олно. Хэрэв бүх тест ОК бол нэгдүгээр алхам руу очно.
3. Тестийг давахын тулд код бичнэ. Кодоо тухайн тестэд л зориулна гэдгийг анхаар илүү дутуу зүйл байх ёсгүй. Ингээд хоёрдугаар алхам руу явна.
Дээрх гурван шаттай хөгжүүлэлтийг арай тестээр хөтлөгдөх хөгжүүлэлт гэхгүй. Test First Development гэдэг. Уг нь бол дээрх дараалал болж байгаа мэт боловч бас нэг юм дутаад байна. Тестээр хөтлөгдөх хөгжүүлэлтэнд язгуурчлал зайлшгүй хэрэгтэй байдаг.
Хоёрдугаар алхмын буюу шинэ тест нэмэхийн өмнө шаардлагатай тохиолдолд язгуурчлал хийснээр дараагийн шинж чанарыг код дээр оруулж ирэхэд хялбар байх болно.
TDD гэдэг бол ерөнхийдөө ийм л зүйл. Урьд нь код бичиж байсан хүнд бол их танил ч гэх юмуу ойр санагдах ёстой доо.
Тестээр хөтлөгдөх хөгжүүлэлт гэдэг ойлголт энэ мянганы эхээр (2000~) ном зохиол болон сонин хэвлэлээр яригдаж хэлэлцэгдэж эхэлсэн боловч бараг ихэнх програм зохиогч энэ аргыг өмнөх мянганд ч хэрэглэж байсан, одоо ч хэрэглэж байгаа гэдэгт итгэдэг.
Жишээ нь сүлжээгээр ямар нэг төхөөрөмжтэй харилцдаг програм хийх боллоо гэж бодоход ихэнх хүн сүлжээгээр холбогдоо байхдаа л програмаа ажиллуулж үзнэ гэдэгт мөрийцөхөд бэлэн байна. Энэ юу вэ гэвэл хамгийн эхний шаардлага буюу прогам ажиллаж эхлэх ёстой гэдгийг шалгаад байгаа хэрэг. Дараа нь сүлжээгээр холбогдож үзэх байх. Тэгээд дараа нь тухайн төхөөрөмж дээрээ ямар нэг команд биелүүлэх, мэдээлэл татаж авах зэрэг үйлдлүүдийг хийж эхлэнэ. Гэхдээ эдгээр үйлдлүүдийг хийх кодуудаа нэг нэгээр нь дараалж бичээд бичсэн болгоноо шалгаж байж дараагийнхаа кодоо нэмэх болов уу? Би л лав ингэж хийнэ, та харин яаж хийх вэ? Хэрэв иймэрхүү маягаар код бичдэг бол та ч гэсэн TDD хийдэг юм байна. Тэгэхээр TDD шинэ юм биш болж таарах нь. Шинэ юм гэдэг бол сайтар мартагдсан зүйл юм гэдэг билүү нэг үг байдаг даа.
Миний удирдаж хийж байсан offshore ажлуудын хөгжүүлэлтийн загвар нь уламжлалт арга барил дээр голчлон явж байлаа. Гэвч бидний хийж байгаа доод түвшний дизайн болоод кодчилолд энэ загвар маань сайн уялдаж өгдөггүй. Учир нь манай хөгжүүлэгчид багаасаа хар практикаараа TDD хийгээд сурчихсан байдгаас тэр байх л даа. Тухайлбал нэг бэлэн хийчихсэн багц функцүүдийг ашиглаад код бичих байлаа гэхэд заавал тэр функцүүдийг ажиллуулж үзэж байж “итгэж” хэрэглэх гээд байх жишээтэй. Гэтэл тэр функц нь онцгой төхөөрөмж болон орчин нөхцөлд ажилладаг учраас ажиллуулж үзэх боломжгүй байх юм бол кодын ажил таг зогсож байгаа юм. Мэдээж туршлагатай хүн бол ажиллуулж үзэлгүйгээр кодоо бичээд дуусгаж чадах л байх. Гэвч манай ихэнх кодеруудад ажиллуулж үзэлгүй кодоо үргэлжлүүлэх сэтгэлзүй суугаагүй л байгаад байх шиг.
Энэ зөрөлдөөнийг арилгахын тулд хөгжүүлэлтийн ерөнхий төлөвлөгөө болоод функционал дизайныг уламжлалт аргачлалаар хийгээд доод түвшний хөгжүүлэлтэд TDD болон бусад agile шалгарсан туршлагуудаас хэрэглэвэл болмоор ч юм шиг. Мэдээж уламжлалт болоод agile хандлагуудад тэс ондоо зүйлс их байдаг ч зарим шалгарсан туршлагуудыг аваад хэрэглэхийг оролдох л хэрэгтэй. Тухайлбал би уламжлалт загвараар хийсэн нилээд олон төсөл дээр Тest case буюу тестийн тохиолдлууд гэдэг баримтыг үйлдэж байсан юм. Гэтэл энэ тестийн тохиолдлуудын баримт маань хөгжүүлэгчид TDD хийх боломжыг нээгээд өгч байгаа юм. Зүй нь бол бид тэстийн тохиолдлуудаа харж байгаад тэстээр хөтлөгдөх хөгжүүлэлт хийчихвэл амар байлтай, гэтэл уламжлалт загвартаа баригдаад кодоо дуусч байж тэстүүдээ хийгээд байдаг.
TDD ийг хэрэглэхэд бүх код тэстэд хамрагддаг гэх мэт давуу талууд бий боловч өгөгдлийн сангийн хөгжүүлэлт, тархсан системийн хөгжүүлэлт зэрэгт хэрэглэхэд хүндрэл гарч болзошгүйг тунгаах хэрэгтэй.