လွယ်လွယ်ပြောရရင် Unit Testing ဆိုတာ ကိုယ့် Code ရဲ့ အပိုင်းသေးသေးလေးတစ်ခုချင်းစီကို သီးသန့်ခွဲပြီး “ဒီအပိုင်းလေး အလုပ်လုပ်လား မလုပ်လား” လို့ စမ်းသပ်တဲ့နည်းပါ။ Program ကြီးတစ်ခုလုံးကို တစ်ခါတည်း စမ်းတာမဟုတ်ဘဲ၊ Function တစ်ခုချင်း၊ အပိုင်းတစ်ခုချင်းစီကို တစ်ခုချင်း စစ်သွားတာပါ။ အပိုင်းသေးသေးလေးတွေ အားလုံး မှန်နေရင် Program ကြီးတစ်ခုလုံးလည်း မှန်ဖို့ ပိုသေချာပါတယ်။
ကျွန်တော် ဒါကို ကားစစ်တဲ့ ဥပမာနဲ့ ပြောချင်တယ်။ ကားတစ်စီး ဝယ်ခင် ကားရောင်းတဲ့သူက ကားကို လမ်းပေါ်မောင်းပြီး “မောင်းလို့ ရတယ်” လို့ပဲ ပြောရင် လုံလောက်လား? မလုံလောက်ပါဘူး။ ဘရိတ် အလုပ်လုပ်လား၊ မီးတွေ လင်းလား၊ ဟွန်း မြည်လား၊ စတီယာရင် လှည့်လို့ ရလား — တစ်ခုချင်းစီကို စစ်ရပါတယ်။ ဘရိတ်မကောင်းတဲ့ ကားကို လမ်းပေါ်ရောက်မှ သိရင် အန္တရာယ်များလွန်းတယ်။ Unit Testing လည်း အတူတူပါပဲ။ Code အပိုင်းတစ်ခုချင်းစီကို စောစောစစ်ထားမှ Program ကြီးကို သုံးတဲ့အခါ အမှားမတွေ့ရတာပါ။
ဥပမာ ရိုးရိုးလေး တစ်ခုကြည့်ရအောင်။ ကိုယ်က ဂဏန်းနှစ်လုံး ပေါင်းတဲ့ Function တစ်ခု ရေးတယ်ဆိုပါစို့။
def add(a, b):
return a + b
Unit Test က ဒီ Function ကို စမ်းတာပါ။
def test_add():
assert add(2, 3) == 5
assert add(0, 0) == 0
assert add(-1, 1) == 0
assert ဆိုတာ “ဒီဟာ ဒီအတိုင်း ဖြစ်ရမယ်” လို့ စစ်တာပါ။ add(2, 3) က 5 မဖြစ်ရင် Test က ကျသွားမယ်၊ ကျသွားရင် ကိုယ် ရေးထားတဲ့ Code မှာ အမှားရှိနေတယ်ဆိုတာ ချက်ချင်းသိရတယ်။ Function ကို ပြင်လိုက်တိုင်း ဒီ Test ကို ပြန်ဖွင့်ကြည့်ရင် “ကိုယ်ပြင်လိုက်တာ ဟောင်းကို ဖျက်မိသလား” ဆိုတာ ချက်ချင်းသိနိုင်ပါတယ်။
Unit Test ကောင်းတစ်ခု ဘယ်လိုရေးရမလဲ?
တစ်ခုတည်းကိုပဲ စမ်းပါ — Test တစ်ခုက Function တစ်ခု၊ အပြုအမူတစ်ခုတည်းကိုပဲ စမ်းသင့်ပါတယ်။ အများကြီး ရောစမ်းရင် ဘယ်ဟာမှားမှန်း ရှာရခက်ပါတယ်။
နာမည်ကို ရှင်းရှင်းရေးပါ — test_add() ထက် test_add_two_positive_numbers() ဆိုရင် ဒီ Test က ဘာစမ်းနေတာလဲ ချက်ချင်းသိရပါတယ်။
ပုံမှန်အခြေအနေရော ထူးခြားတဲ့ အခြေအနေပါ စမ်းပါ — ဥပမာ add(2, 3) လို ပုံမှန်ဟာရော၊ add(0, 0) လို ထူးခြားတဲ့ဟာပါ စမ်းပါ။ သုညနဲ့ အနုတ်ဂဏန်းတွေက အမှားအများဆုံး ထွက်တဲ့နေရာပါ။
Test ကို မြန်မြန်ဖွင့်လို့ ရအောင် ရေးပါ — Test တွေ နှေးရင် လူက မဖွင့်ဖြစ်တော့ပါဘူး။ Unit Test က စက္ကန့်ပိုင်းအတွင်း ပြီးရမှာပါ။
Test-Driven Development (TDD) ဆိုတာ ဘာလဲ?
Unit Testing နဲ့ တွဲပြီး ကြားရတတ်တဲ့ စကားတစ်လုံးက TDD ပါ။ TDD ဆိုတာ Code မရေးခင် Test ကို အရင်ရေးတဲ့နည်းပါ။ အဆင့် ၃ ဆင့်ပါ။
Red — အရင်ဆုံး Test ရေးတယ်။ Code မရှိသေးတော့ Test က ကျတယ် (အနီရောင်)။
Green — Test အောင်ဖို့ လိုအပ်တဲ့ Code အနည်းဆုံးကို ရေးတယ် (အစိမ်းရောင်)။
Refactor — Code ကို သန့်ရှင်းအောင် ပြန်ပြင်တယ်၊ Test က အောင်နေဆဲပဲ ဖြစ်ရမယ်။
TDD က စစချင်း ထူးဆန်းသလို ထင်ရပေမယ့်၊ ကိုယ် ဘာဆောက်ချင်တာလဲ ဆိုတာ အရင်စဉ်းစားခိုင်းတာပါ။ Test ကို အရင်ရေးတော့ “ဒီ Function က ဘာလုပ်ပေးရမလဲ” ဆိုတာ ရှင်းသွားပြီး Code ရေးရတာ ပိုလွယ်သွားပါတယ်။
Unit Test ကို ဘယ်အချိန်မှာ ရေးသင့်လဲ?
ကျွန်တော့်အတွေ့အကြုံအရတော့ Unit Test ကို အရေးကြီးတဲ့ Function တွေမှာ ရေးသင့်ပါတယ်။ ဥပမာ ပိုက်ဆံတွက်တဲ့ Function၊ Password စစ်တဲ့ Function၊ Data သိမ်းတဲ့ Function — ဒါတွေက မှားရင် တိုက်ရိုက် ထိခိုက်တာမို့ Test ရှိရပါမယ်။
Python မှာ Test ရေးဖို့ pytest ကို သုံးလေ့ရှိပါတယ်။ pip install pytest လုပ်ပြီး pytest လို့ ရိုက်လိုက်ရုံနဲ့ Test တွေ အကုန် ဖွင့်ပေးပါတယ်။ JavaScript မှာ Jest၊ Java မှာ JUnit — ဘာသာစကားတိုင်းမှာ ကိုယ့်ရဲ့ Test Tool ရှိနေပါတယ်။
Unit Test မရေးတဲ့ Developer တွေက “အချိန်ကုန်တယ်” လို့ ထင်တတ်ကြပါတယ်။ တကယ်တော့ ဆန့်ကျင်ဘက်ပါ။ Test မရှိရင် Bug တစ်ခု ထွက်တိုင်း ဘယ်နေရာက မှားတာလဲဆိုတာ လိုက်ရှာရတာ အချိန်အများကြီး ကုန်ပါတယ်။ Unit Test ရှိရင် Bug ထွက်တာနဲ့ ဘယ်အပိုင်းက မှားတာလဲ ချက်ချင်းသိရတယ်။ ကိုယ့် Code ကို ယုံကြည်မှုရှိရှိ ပြင်နိုင်တယ်။ ဒါကြောင့် Unit Test က အချိန်ကုန်တာ မဟုတ်ဘဲ အချိန်သက်သာအောင် လုပ်ပေးတဲ့ အရာပါ။ 🙂
