user
Test-driven Development in software engineering

Test Driven Development ကိုအသုံးပြုပြီး project တွေ ဘယ်လိုရေးရမလဲ။ TDD ဆိုတာ ဘာလဲ။ ဘာကြောင့် အချို့ software engineer တွေက TDD ကိုကြိုက်ကြတာလဲ။ test-driven development အကြောင်း အရိုးရှင်းဆုံး နားလည်သွားစေအောင် ပြောပြပေးပါ
assistant
test-driven development ဆိုတာ တိုတိုပြောရရင် code ချမရေးခင် test တွေအရင်ရေးထားဖို့ပါပဲ။ ဒါဟာ အိမ်တလုံး မဆောက်ခင်မှာ နံရံ၊ မျက်နှာကျက်၊ ဖောင်ဒေးရှင်း စသဖြင့် ခိုင်ခံ့မှု ရှိမရှိ စစ်ဆေးဖို့ ကိရိယာတွေ အရင်ဝယ်လိုက်တာနဲ့ တူပါတယ်။ စစချင်းမှာတော့ ကိုယ်လိုချင်တဲ့ ကြံ့ခိုင်မှုစံနှုန်း ပြည့်ဦးမှာ မဟုတ်ပေမယ့် ရည်မှန်းထားတဲ့ test case တွေအတိုင်း feature တခုပြီးတခု စံမှီလာတဲ့အထိ တည်ဆောက်သွားတာကို TDD လို့ခေါ်တာဖြစ်တယ်။
TDD အကြောင်းပြောရင် Red, Green နဲ့ Refactor ကို ချန်ခဲ့လို့ မဖြစ်ပါဘူး။
TDD ကိုစတင်ဖို့ ကိုယ်လိုချင်တဲ့ feature အတွက် test case တွေ အရင်စရေးရပါတယ်။ ဒါပေမယ့် တကယ်အလုပ်လုပ်နိုင်အောင် ဘာ code မှရေးမထားရသေးတဲ့အတွက် test က fail မှာအသေအချာပါပဲ။ ဒါကို အနီရောင်အဆင့် (Red) လို့ခေါ်ပါတယ်။ အနီရောင်အဆင့်မှာ program က အလုပ်မလုပ်နိုင်သေးတာကို ကြိုသတိပေးနေတဲ့အတွက် traffic မှာ မီးနီပြထားတာနဲ့ တူပါတယ်။
အစိမ်းရောင်အဆင့် (Green) မှာတော့ test အောင်ဖို့ လိုအပ်လောက်ရုံ code တွေစရေးပါတယ်။ ဒီအဆင့်မှာ ဖြစ်နိုင်သမျှ အကောင်းဆုံး code quality ရဖို့ကို အာရုံထဲ မထည့်သေးပဲ feature တခု အလုပ်လုပ်ဖို့ လိုသလောက်သာ ရေးကြဦးမှာပါ။ ရေးပြီးတဲ့အခါ စောစောက fail နေတဲ့ test တွေ အောင်ရမှာဖြစ်ပြီး code က ကိုယ်လိုချင်သလို အလုပ်လုပ်ပြီဆိုတာနဲ့ နောက်ထပ် ရှေ့ဆက်နိုင်ပြီဖြစ်လို့ traffic ရဲ့ မီးစိမ်းနဲ့ တူပါတယ်။
နောက်ဆုံးအဆင့်ကတော့ Refactor ပါ။ ဒီအဆင့်မှာ test အောင်နေပြီးဖြစ်တဲ့ feature တခုကို အခုထက် ပိုကောင်းကောင်း အလုပ်လုပ်နိုင်အောင် ပြင်ဆင်မွမ်းမံတာတွေ ဆက်လုပ်ကြပါတယ်။ နားလည်ရ လွယ်ပြီး ပိုထိထိရောက်ရောက် အလုပ်လုပ်နိုင်မယ့် code တွေဖြစ်အောင် ပြင်ဆင်ကြတဲ့အခါ bug တွေပါပါသွားလို့ program ကအလုပ်မလုပ်တော့တာမျိုး မကြာခဏ ကြုံရတတ်ပါတယ်။ TDD မှာတော့ ရေးရင်းနဲ့ လွယ်လွယ်ပဲ စစ်သွားနိုင်တဲ့အတွက် တချို့ software developer တွေက TDD ကိုသဘောကျကြပါတယ်။
TDD ရဲ့ ဖီလော်ဆော်ဖီက ကိုယ်ရေးထားတဲ့ code အလုပ်လုပ်ရဲ့လား သိနိုင်အောင် စောစော စမ်းသပ်ဖို့နဲ့ မကြာခဏ စမ်းသပ်ဖို့ပါပဲ။ ဒါကြောင့် TDD ကိုမှန်မှန် ကျင့်သုံးမယ်ဆိုရင် error တွေကို စောစော မြင်ရမှာဖြစ်လို့ ဘယ်ကစရှင်းရမသိလောက်အောင် error တွေစုမိလာတာမျိုး ဖြစ်နိုင်ချေ နည်းပါတယ်။
နောက်ပြီး TDD နဲ့ project တွေရေးကြတဲ့အခါ code ကို ရဲရဲ ပြင်လို့ရစေတဲ့အတွက် အလုပ်လုပ်တာ သေချာရင် မထိနဲ့တော့ဆိုတဲ့ အယူအဆကနေလည်း ကာကွယ်ပေးပါတယ်။ အထပ်မြင့်တိုက်ကြီး ဆောက်တဲ့အခါ ဖောင်ဒေးရှင်း မချခင်ကတည်းက အစိတ်အပိုင်းတခုစီမှာ ရှိသင့်ရှိထိုက်တဲ့ ခိုင်ခံ့မှု စံနှုန်းတွေကို ကြိုသတ်မှတ်ပြီး အုတ်တပြားချင်းကို စံမှီမမှီ စစ်ဆေးတည်ဆောက်ခဲ့မယ်ဆိုရင် နှစ်ပေါင်းအတော်ကြာ နေသွားလို့ရမယ့် အိမ်မျိုးဖြစ်လာမှာပါ။
ဆိုရရရင် ကိုယ့် code က တကယ် အလုပ်လုပ်ပါ့မလားလို့ တွေးပူစရာမျိုးကို Red, Green, Refactor အဆင့်တွေ ပါဝင်တဲ့ Test-driven development တခုတည်းနဲ့တင် ဖြေရှင်းနိုင်တယ်လို့ ပြောလို့ရတယ်။ ချွင်းချက်အနေနဲ့ အာရုံစိုက်စရာများတဲ့ microservice တွေ မဟုတ်ခဲ့ရင်ပေါ့။

မှတ်ချက်။   ။ CodeHub with Harry မှ Harry Yan ရဲ့့ ၂၀၂၃၊ သြဂုတ်လက စာတပုဒ်ဆီမှ ကောက်နှုတ်ထားသည်