ပြီးခဲ့တဲ့ သောကြာနေ့က MCPA Meeting Room မှာ ပြုလုပ်ခဲ့တဲ့   ဆွေးနွေးပွဲတစ်ခုကို တက်ဖြစ်ခဲ့ပါတယ်။ အဲ့ဒီ Event မှာ Singapore နဲ့ Australia မှာ Programmer အဖြစ်လုပ်ကိုင်နေတဲ့ Raymond Maung ခေါ် ကိုရန်နောင်က Test Driven Development (TDD) အကြောင်း သိကောင်းစရာများကို ရှင်းလင်းပြောပြခဲ့ပါတယ်။

Agile Practice တွေထဲက တစ်ခုလို့ ယူဆထားတဲ့ TDD ကို အရင်ကတည်းက စိတ်ဝင်စားပါတယ်။ Production Code နဲ့အတူ Test Code ကို တစ်ခါတည်းရေးရမယ်ဆိုတဲ့ Concept ကို ကောင်းကောင်းနားမလည်သလို၊ အလုပ်ဖြစ်လိမ့်မယ်လို့လဲ မယုံကြည်ခဲ့ပါဘူး။ ဒါပေမယ့် ကိုရန်နောင်ရှင်းပြတာကိုနားထောင်ပြီးတဲ့နောက်မှာတော့၊ TDD ဆိုတာဟာ Agile တို့ Waterfall တို့လို Methodology တွေအပေါ်မှာ မူတည်နေခြင်းမဟုတ်ပဲ (မည်သည့် Methodology ကိုပဲသုံးသုံး လိုက်နာနိုင်တဲ့) သီးခြားနည်းစနစ်တစ်ခုသာဖြစ်တယ် ဆိုတဲ့အချက်နဲ့ TDD ရဲ့ အကျိုးကျေးဇူးတွေကို မြင်လာရပါတယ်။

ကိုရန်နောင်ရဲ့ Presentation ထဲက တစ်ချို့အချက်တွေကို ဒီနေရာကနေ ပြန်လည် ဝေမျှပေးလိုက်ပါတယ်။ တစ်ပါတည်းရှင်းပြခဲ့တဲ့ အချက်တွေကိုလည်း ကျွန်တော်မှတ်မိ နားလည် သလောက် ပူးတွဲ ဖော်ပြလိုက်ပါတယ်။

Programming ဆိုတာဟာ အကြိမ်ကြိမ်ပြန်လုပ်ရမယ့်အလုပ်တွေကို လူကိုယ်တိုင်မလုပ်ပဲ ကွန်ပျူတာကို လုပ်ခိုင်းခြင်းပဲဖြစ်ပါတယ်။ ဘယ်လောက်ကြီးမားရှုပ်ထွေးတဲ့ Software ပဲဖြစ်ဖြစ် အရင်းစစ်လိုက်ရင် ဒီသဘောပါပဲ။ အကြိမ်ကြိမ်ပြန်လုပ်ရတဲ့အလုပ်တွေကို လုပ်တဲ့နေရာမှာ ကွန်ပျူတာက လူထက်သေချာပါတယ်။

Software တစ်ခုတည်ဆောက်တဲ့အခါမှာ Agile Development ကိုပဲသုံးသုံး Waterfall Methodology ပဲသုံးသုံး ပါဝင်တဲ့အဆင့်တွေကတော့ အခြေခံအားဖြင့် အတူတူပါပဲ။ အဲ့ဒီအဆင့်တွေထဲက Requirement, Development, Test, Production စတဲ့အဆင့်တွေဟာ အရင်းအနှီးတွေဖြစ်ပါတယ်။ ဘယ်စီးပွားရေးမဆို အရင်းအနှီးပမာဏကို လျှောချနိုင်ရင် ဈေးပေါပေါနဲ့ရောင်းနိုင်မယ်၊ အမြတ်ပိုများများရနိုင်ပါမယ်။ Software Development မှာလဲ အရင်အနှီးဖြစ်တဲ့အဆင့်တွေမှာ အချိန်ကုန် ငွေကုန်သက်သာအောင် လျှောချနိုင်တာနဲ့အမျှ ပိုမိုထိရောက်အောင်မြင်နိုင်ပါတယ်။

TDD ဆိုတာဟာ အလိုအလျှောက် Test လုပ်ပေးတဲ့ Code ကို Software ရဲ့ Production Code နဲ့အတူ တစ်ပြိုင်တည်းရေးတဲ့ နည်းစနစ်တစ်ခုဖြစ်ပါတယ်။ Software ရဲ့ အဆင့်တိုင်းအတွက် Automate Test Code တွေရေးထားပေးရမှာပါ။ ဒီနည်းနဲ့ အမြဲတမ်းမှန်နေတဲ့ Production Code ကိုလည်း ရနိုင်ပါတယ်။

Test Driven Development လို့ခေါ်ရတဲ့အကြောင်းရင်းကတော့ Automate Test Code ကို အရင်ရေးရတဲ့ နည်းစနစ်တစ်ခုဖြစ်တဲ့အတွက် ဖြစ်ပါတယ်။ Test Code ကိုအရင်ရေးခြင်းအားဖြင့် ကိုယ့်ရဲ့ Software ဟာ ဘယ်လိုဘယ်ပုံအလုပ်လုပ်ရမယ်ဆိုတာကို တစ်ခါတည်း သတ်မှတ်ပြီးသားဖြစ်သွားပါတယ်။ Software တစ်ခုကို Design လုပ်တဲ့အခါ ရှင်းလင်းတဲ့ Spec တွေဟာ အရေးပါပါတယ်။ Test ကိုအရင်ရေးခြင်းဟာ Software ကို ဘယ်လို Design လုပ်မယ်လို့ Spec ထုပ်လိုက်သလိုပါပဲ။

Test Code ကို အရင်ရေးခြင်းအားဖြင့် Software တည်ဆောက်သူဟာ အခုဘာလုပ်ရမယ်၊ နောက်တစ်ဆင့် အနေနဲ့ ဘာဆက်လုပ်ရမယ်၊ ဘယ်အဆင့်ရောက်တဲ့အခါ ပြီးမယ်ဆိုတဲ့အချက်တွေကို ရှင်းရှင်း သိနေနိုင်ပါတယ်။ တစ်ခြားအကျိုးကျေးဇူးတွေ အများကြီးရှိပါသေးတယ်။ စနစ်ကျတဲ့ Modular Code Structure ကိုရနိုင်ပါတယ်။ Dependencies တွေနဲ့ပက်သက်ပြီးတော့လဲ ပိုမိုတိကျစွာ သတ်မှတ်အသုံးပြုနိုင်ပါတယ်။ မလိုအပ်ပဲ ပိုလုပ်မိတာမျိုးတွေကို ရှောင်ရှားနိုင်ပါတယ်။ လိုရင်းကတော့ Test ဟာ Spec ဖြစ်နေတဲ့အတွက် ပိုမိုထိရောက်လာခြင်းပဲဖြစ်ပါတယ်။

Automate Test လို့ပြောရင် အများစုက Unit Test ကိုပဲပြေးမြင်တက်ကြပါတယ်။ အမှန်တော့ Unit Tests, Acceptance Tests (Functional Tests), Integration Tests စတဲ့အဆင့်တွေကိုလဲ Automate လုပ်လို့ရနိုင်ပါတယ်။

Automate Test လုပ်တဲ့အတွက် Bug ပမာဏကို လျှော့ချနိုင်ပါတယ်။ စိတ်ချလက်ချ Refactor လုပ်နိုင်ပါတယ်။ အဲ့ဒီလို စိတ်ချလက်ချ Refactor လုပ်နိုင်တဲ့အတွက် Duplicate ဖြစ်နေတဲ့ကိစ္စတွေကိုလည်း လျှော့ချနိုင်ပါတယ်။ ပိုမိုရိုးရှင်းကျစ်လစ်တဲ့ Code ကိုရနိုင်ပါတယ်။

Test ဆိုတာ Program မဟုတ်ပါဘူး။ ရိုးရှင်းတဲ့ Spec တစ်ခုပဲဖြစ်ပါတယ်။ ဒါကြောင့် Test Code မှာ Conditional Logic တွေမပါသင့်ပါဘူး။ ဒါထည့်လိုက်ရင် ဒါထွက်ရမယ်ဆိုတဲ့ ရှင်းလင်းတဲ့ သတ်မှတ်ချက်မျိုးနဲ့ပဲ Test လုပ်သင့်ပါတယ်။ ဒီအချက်ကအရေးကြီးပါတယ်။ မဟုတ်ရင် Test Code ကိုယ်တိုင်ကရှုပ်ထွေးလာပြီး ဂျာအေးကိုသူ့အမေရိုက် ဖြစ် သွားပါမယ်။

Test Driven Development ရဲ့ Process က ဒီလိုပါ။ ပထမဦးဆုံး Test ကိုအရင်ရေးပါ (တနည်းအားဖြင့် ဘယ်လိုအလုပ်စေချင်လဲဆိုတဲ့ သတ်မှတ်ချက်ကို ရေးလိုက်တာပါပဲ)။

Software ကို အဲ့ဒီ Test ကို စမ်းကြည့်လိုက်ရင် Pass ဖြစ် နေအောင်ရေးပါ။ ရေးချင်သလိုရေးပါ။ အစပိုင်းမှာ ရေးထားတဲ့ Code က သိပ်ရှုပ်ထွေးနေတယ်ဆိုလဲ ဖြစ်ပါတယ်။ Test Pass ဖြစ်ဖို့ကအဓိကပါ။ Test Pass ဖြစ်သွားပြီဆိုတော့မှ ရေးထားတဲ့ Code ကို Refactor ပြန်လုပ်ပါ။ Refactor လုပ်ပြီးရင် Test နဲ့ တစ်ခေါက်ပြန်စမ်းပါ။ ဒီလိုနဲ့ နောက်ဆုံးမှ လိုအပ်ချက်အတိုင်း အလုပ်လုပ်ပြီး ကျစ်လစ်တဲ့ Code  နဲ့ Software ကို ရနိုင်ပါတယ်။

Unit Tests, Acceptance Tests နဲ့ Integration Tests ဆိုတဲ့အဆင့်တိုင်းအတွက် Automate Test လုပ်လို့ရတဲ့ Framework တွေ Tools တွေ အများကြီးရှိပါတယ်။ အခုဖော်ပြထားတာတွေက နမူနာပဲ ရှိပါသေးတယ်။ ရှာဖွေးစမ်းသပ်ပြီး လေ့လာကြည့်စေချင်ပါတယ်။

ရေးထားပြီး အလုပ်လုပ်နေတဲ့ Code ကို Refactor လုပ်ရမယ်ဆိုရင် အားလုံးက ကြောက်ကြပါတယ်။ Refactor လုပ်လိုက်မှ မှားသွားပြီး အလုပ်မလုပ်တော့မှာကို ကြောက်တာပါ။ အမှန်တော့ မှားသွားတာက ပြဿနာမဟုတ်သေးပါဘူး။ ပြင်လိုက်လို့ရပါတယ်။ ပြဿနာက မှားသွားမှန်းမသိလိုက်မှာကို ကြောက်ကြတာပါ။ မူလကအလုပ်လုပ်နေတယ်။ ပြီးတော့ပြင်လိုက်တယ်။ ပြန်စမ်းကြည့်တယ်။ အလုပ်လုပ်နေသေးတယ်။ ဒါပေမယ် ဘယ်လောက်ထိ ပြန်စမ်းကြည့်နိုင်မှာလဲ။ ပြန်စမ်းကြည့်တော့ အဆင်ပြေနေပေမယ့် Client ဆီရောက်သွားတော့မှ အလုပ်မလုပ်တော့ရင်ရော ဘယ်လိုလုပ်မလဲ?

အတွေ့အကြုံရှိတဲ့သူတိုင်းသိပါတယ်။ ပြင်လိုက်တဲ့ Code က ဒီနားမှာအဆင်ပြေနေပေမယ့်။ ဟိုး တစ်ခြားနေရာမှာ သွားပြီး ပြဿနာတက်နေတက်ပါတယ်။

ဒီလိုပြဿနာတွေရှိတော့ Code Refactor လုပ်ဖို့ဆိုတာ တစ်ကယ့်ကို စွန့်စားခန်းကြီးဖြစ်နေပါတယ်။ Automate Test ရှိနေမယ်ဆိုရင်တော့ စိတ်ချလက်ချ Refactor လုပ်နိုင်ပါလိမ့်မယ်။ Refactor လုပ်လိုက်၊ Automate Test လေးပြန် Run လိုက်ဆိုရင် မှားသွားလဲ ချက်ခြင်းသိနိုင်ပါတယ်။

Refactor လုပ်တဲ့နည်းလမ်းတွေအများကြီးရှိပါတယ်။ အလွယ်ဆုံးနည်းကတော့ နာမည်ပြောင်းလိုက်တာပါပဲ။ Variable Name တွေ Object Name, Method Name, Property Name တွေကို အဓိပ္ပါယ်ရှိတဲ့ အမည်တွေပြောင်းပေးတာကနေ စသင့်ပါတယ်။ အမည်တွေက အဓိပ္ပါယ်ရှိယုံတင်တော့မရသေးပါဘူး၊ Misleading မဖြစ်ဖို့လဲလိုပါတယ်။ ဥပမာ - ပြောတော့ totalPayment - လုပ်တော့ တစ်ခြားအလုပ်ဆိုရင်လည်း မဟုတ်သေးပါဘူး။

အိမ်တစ်လုံးဆောက်ပြီးရင် ငြမ်းတွေဖျက်ပေးရပါတယ်။ သန့်ရှင်းရေးလုပ်ပေးရပါတယ်။ ဆောက်လို့ပြီးပြီ၊ နေတော့ ဆိုပြီးပြောလို့မရပါဘူး။ အတူတူပါပဲ၊ Software တစ်ခုရေးပြီးပြီဆိုရင်လည်း Refactor လုပ်ပေးရပါတယ်။ TDD က စိတ်ချလက်ချ Refactor လုပ်နိုင်ဖို့ ကူညီပေးပါတယ်။

TDD က ပြောရတာလွယ်ပေမယ့် လက်တွေ့လုပ်ရတာခက်ပါတယ်။ အများကြီးဆက်လက်လေ့လာလို့ရပါသေးတယ်။ TDD နဲ့အတူ Continues Integration, Behavior Driven Development, Design Pattern စတဲ့ အခြား Practice တွေကိုလည်း တွဲဖက်လေ့လာသင့်ကြောင်း ပြောချင်ပါတယ်။

Q&A

Q - ဒီနည်းလမ်းကို သုံးမယ်ဆိုရင် Test က ဘယ်သူ့ရဲ့တာဝန်လဲ။ Tester ရဲ့တာဝန်လား၊ Programmer ရဲ့တာဝန်လား? Tester တွေ မလိုအပ်တော့ဘူးလား?

A - အဲ့လိုတော့ ပုံသေပြောလို့မရပါဘူး။ Purpose က မတူပါဘူး။ Tester တွေ Test လုပ်တယ်ဆိုတာက Functionally ကို Test လုပ်တာပါ။ အခုပြောတဲ့ TDD က System Level မှာ Bug တွေနည်းအောင်၊ Design ကောင်းအောင် Test လုပ်တဲ့သဘောပါ။

Q - Test Code ကိုအရင်ရေးရမယ်ဆိုတော့ ဘယ်အချိန်မှာ စရေးရမှာလဲ? Project Development Lifecycle ရဲ့ ဘယ်အဆင့်မှာ စရေးရမှာလဲ?

A - အဲ့ဒါက ကိုယ်အသုံးပြုနေတဲ့ Methodology နဲ့ စနစ်ပေါ်မှာ မူတည်ပါတယ်။ Waterfall Model နဲ့လုပ်နေတာဆိုရင်တော့ Implementation / Coding အဆင့်မှာ Test Code ကိုရေးရမှာပါ။ ဘယ် Methodology ပဲသုံးသုံး Test Code ရေးဖို့အတွက် Requirement တော့လိုပါတယ်။ Requirement ရပြီးပြီဆိုမှ စရေးရမှာပါ။

ဒီ Event မှာ  ရှင်းလင်းပြောပြပေးတဲ့ ကိုရန်နောင်ကို ကျေးဇူးတင်ကြောင်း ဒီနေရာကနေ ပြောလိုပါတယ်။ တစ်ဆက်တည်းမှာပဲ ပြည်ပရောက်နေတဲ့ ပညာရှင်များအနေနဲ့ ကျွန်တော်တို့ ပြည်တွင်းက လူငယ်များအတွက် အလျှင်းသင့်ရင်သင့်သလို ဒီလို အသိပညာမှုများ ဝေမျှမှုများ လုပ်ပေးကြပါလို့ တောင်းဆိုလိုက်ပါတယ်။

ကျေးဇူးတင်ပါတယ်။