Category Archives: Unit Testing

ทำ Unit Testing แล้วมันใช้เวลา พลัง และเงิน มากขึ้น จริงหรือ? (ตอนที่ 2)

unit-testing-welovebug

สวัสดีเช้าวันพุธที่ 13 สิงหาคม พ.ศ. 2557 ตอนนี้ก็เวลาประมาณ 05:32น. เป็นวัยรุ่นเลยต้อง นอนดึก ตื่นเช้า เลยมาจรดปลายนิ้ว บ่นเรื่อง Unit Testing ทำแล้วมันใช้เวลา พลัง และเงิน มากขึ้น จรงิหรือ? ตอนที่ 2 ต่อ กับ 2 คำถาม

เราไม่ได้คิดค่าทำ Unit Testing ไปตอนประเมินราคาให้ลูกค้า
ลูกค้าไม่ได้จ่ายเงินมาเพื่อให้เรามานั่งเขียน Unit Testing นะ

Continue reading ทำ Unit Testing แล้วมันใช้เวลา พลัง และเงิน มากขึ้น จริงหรือ? (ตอนที่ 2)

ทำ Unit Testing แล้วมันใช้เวลา พลัง และเงิน มากขึ้น จริงหรือ? (ตอนที่ 1)

unit-testing-welovebug

เมื่อได้ก้าวเดินมาในเส้นทางของการเป็น Agile Coach และ ScrumMaster เรื่องหนึ่งที่ผมยังให้ความสำคัญอยู่เสมอคือ คุณภาพ (Quality) ซึ่งการทดสอบยังคงเป็นเรื่องสำคัญมากๆๆๆ ดังนั้นเมื่อใช้ และประยุกต์ใช้ Agile เข้าช่วย หรือใช้เป็นหลักในการพัฒนา Software แล้วนั้น ผมก็จะขายแนวคิดเรื่องของการทำ Unit Testing โดยใช้ Test-Driven Development (TDD) เข้ามาช่วยทีมพัฒนา แต่ก็มักจะเจอคำถามจากผู้คนในระดับหัวหน้าทีม และระดับฝ่ายบริหารเสมอๆ ว่า

ทำ Unit Testing แบบนี้ มันก็ต้อง

ใช้เวลามากขึ้นสิ ใช้ Effort มากขึ้นสิ
ใช้เงินเพิ่มขึ้นสิ
เราไม่ได้คิดค่าทำ Unit Testing ไปตอนประเมินราคาให้ลูกค้า
ลูกค้าไม่ได้จ่ายเงินมาเพื่อให้เรามานั่งเขียน Unit Testing นะ

ผมก็อดยิ้มไม่ได้ 🙂

Continue reading ทำ Unit Testing แล้วมันใช้เวลา พลัง และเงิน มากขึ้น จริงหรือ? (ตอนที่ 1)

[Discussion] ปัญหาของ Unit Testing Framework … คุณจะแก้ไขอย่างไร

ไปอ่านเจอบทความเกี่ยวกับการพูดถึงปัญหาของ Unit Testing Framework ในปัจจุบัน ซึ่งแบ่งออกเป็นหัวข้อได้ได้นี้

1. Lack of Automation
2. Focus on test instead of code
3. Take too much time
4. Weak mocking
5. Coverage

เลยอยากจะเปิดเป็น open discussion สำหรับปัญหาต่างๆ เพื่อหาวิธีการแก้ไข หรือปรับความเข้าใจใหม่ เพื่อไม่ให้เกิดปัญหา ใครมีแนวคิดดีๆ ก็สามารถ share ได้เลยครับ

Case Study: สู้รบปรบมือกับการทดสอบที่มี IP Address มาเกี่ยวข้อง

สวัสดียามค่ำของวันเสาร์ที่ 13 มีนาคม 2553 ครับ เปิดหัวเรื่องของวันนี้ด้วยคำว่า Case Study เนื่องด้วยเรื่องที่จะแบ่งปันในค่ำคืนนี้เป็น Case ที่เกิดขึ้นจริง หรือที่ฝรั่งมักจะใช้คำว่า Base on True Story ครับ และเกิดขึ้นใน ห้องน้ำ อ้าว งง งง งง กันเลยทีเดียวครับ ถ้าอยากรู้ว่า Software Testing ไปเกี่ยวข้องอะไรกับ ห้องน้ำ อ่านกันต่อไปครับ 🙂

Case Study นี้เกิดขึ้นเมื่อเกือบจะ 2 ปีแล้วครับ และติดตึงอยู่ในสมองน้อยๆ ของผมมานานเลยทีเดียว ว่าจะเขียน ว่าจะเขียน และว่าจะเขียน ลง welovebug มานานสองนาน แต่จนแล้วจนรอดก็ไม่ได้เขียนสักที ค่ำคืนนี้เลยตั้งใจว่าจะเขียนมันออกมา เผื่อจะได้เป้นประโยชน์ไม่มากก็น้อยสำหรับเพื่อนพ้องน้องพี่ทั้ง Software Tester, Programmer และ Developer ครับ

โจทย์ที่เจอจนต้องเอาต้องเอา ตีx ก่ายหน้าผาก

เพื่อนพ้องน้องพี่ทั้งหลายน่าจะคุ้นเคยกับการ Vote ให้คะแนนบน website ต่างๆ ไม่ว่าจะ Vote ให้คะแนนรูปที่ชอบ หรือ ช่วย Vote ให้เพื่อนๆ ที่ประกวดโน้นนี่นั่นบน website หรือ แสดงความคิดเห็น หรือ Comment บน Webboard หรือ Forum หรือ Discussion ที่มีอยู่เยอะแยะมากมายตาม website ต่างๆ ซึ่งเจ้า Vote และ Comment นี่แหละ ที่ทำให้ผมถึงกับต้องนอนเอา ตีx ก่ายหน้าผาก อยู่นานหลายเดือน

โจทย์ที่ได้รับมาเป็น Project ที่จะต้องทำการทดสอบ Function การ Vote ให้คะแนนกับบทความที่เขียน และมี Business Requirement หลักคือ

1 IP Address สามารถ Vote ได้ 1 ครั้ง ทุกๆ 1 ชั่วโมง

หลายคนอาจจะทำหน้า งง งง ว่า แค่ Business Requirement ข้อเดียว ถึงกับทำให้ผมต้องนอนเอา ตีx ก่ายหน้าผาก ได้อย่างไร?
Continue reading Case Study: สู้รบปรบมือกับการทดสอบที่มี IP Address มาเกี่ยวข้อง

มาใช้ Functional Testing กัน

หลังจากที่ไป download grails มาจาก github เห็นว่ามี folder นึงที่น่าสนใจคือ grails-functional-tests คำถามแรกคือ มันคืออะไร ? เพราะว่าปกติทำแต่ unit test ธรรมดาทั่วไป

รูปจาก www.grails.org

ดังนั้นจึงไปทำการค้นหาพบว่า function test มันเป็น plugin ตัวหนึ่งของ Grails อยู่ที่นี่ Functional Test Plugin

และมีการเปรียบเทียบกับ WebTest ไว้ที่นี่

หลังจากที่ไปอ่านมา ได้ข้อสรุปคร่าวๆ ว่า Functional Test คือ
– plugin ของ grails
– HTTP Testing นั่นเอง โดยข้างในมันคือ HtmlUnit หรือตัวยิง web
– ใช้ DSL ของ groovy ซึ่งเป็นข้อดีและเข้ากันดี ไม่ต้องไปเขียน xml ให้ยุ่งยาก

พอรู้ถึงข้อมูลคร่าวๆ ของ Functional Test แล้วก็ถึงเวลานำมันมาใช้งานกันดีกว่า

Continue reading มาใช้ Functional Testing กัน

PHPSpec

ไม่มีอะไรดีเท่าการทดลอง เริ่มต้นด้วยการติดตั้ง
– ชุด PHP ด้วย xampp (appserv ก็ ok แล้วแต่รสนิยม)
– ตามด้วย Pear เวอร์ชันล่าสุด เพราะ PHPSpec require php และ pear เวอร์ชันค่อนข้างใหม่
ติดตั้ง PHPSpec

ขอข้ามวิธีติดตั้งละกันครับ(ตาม link ก็ได้) เพราะอยากจะให้เห็นการเขียน spec มากกว่า

require_once ‘LazyDog.php’;
class DescribeLazyDogEating extends PHPSpec_Context
{
private $_dog = null;

public function before()
{
$this->_dog = new LazyDog(“Neng”);
}

public function itShouldGetFullAfterEatRiceTwice()
{
$this->_dog->eat(“rice”);
$this->_dog->eat(“rice”);
$this->spec($this->_dog->speech)->should->equal
(“I’m eating rice and I’m full now grrrrrr grrrrrr”);
}

public function itShouldNotGetFullAfterEatRiceOnce()
{
$this->_dog->eat(“rice”);
$this->spec($this->_dog->speech)->should->equal
(“I’m eating rice and I need more food grrrr”);
}
}

before คือ ก่อนที่มันจะไปอ่าน spec ในแต่ละตัว จะรัน code ใน before ก่อน

spec อันแรกคือ it should get full after eat twice คิดว่าไม่ต้องแปลมั้ง ??
ก็เขียนไปเลย eat 2 ที
spec อันที่สองคือ it should not get full after eat once
ก็เขียน eat ไว้ทีเดียวพอ

ถ้าเรามองเป็นหน่วย(unit) ในกรณีนี้ แค่ทดสอบ eat method ก็พอ ส่งอะไรไป แล้วได้รับอะไรมา แล้วเขียนยืนยัน(assert) เอาอีกทีว่าตรงตามที่เรา

ต้องการไหม
แต่ถ้าเรามองเป็นพฤติกรรม่(behavior) คือ มันทำอะไรไปบ้าง มันจะครอบคลุมรายละเอียดได้มากกว่า การตรวจสอบในระดับ unit

ผลพลอยได้จากการเขียน test ก่อนคือเรารู้ funcnality ที่แน่นอนว่าเราต้องการอะไร จะช่วยลดการเขียน code ในส่วนที่ไม่จำเป็น

หน้าตาจากการ implement บน PHP ก็ประมาณนี้(ผมเพิ่มอะไรไปอีกหลายอย่าง สำหรับการ test)

class LazyDog {
private $name;
private $hungry = 100;
public $speech = “”;
function __construct($name=”Achmed”) {
$this->name = $name;
}

public function say(){
return “My name is “.$this->name.”.”;
}

public function bark(){
$this->hungry += 10;
}

public function sleep(){
$this->hungry = 100;
return “grrrrrr grrrrrr”;
}

public function eat($food=null){
$this->speech = “I’m eating “.$food.” and “;
switch($food){
case “rice” :
$this->hungry -= 50;
break;
case “water” :
$this->hungry -= 20;
break;
default:
$this->speech .= “I can’t eat !!! “;
}

if($this->hungry speech .= “I’m full now “;
$this->speech .= $this->sleep();
}else
$this->speech.= “I need more food grrrr”;
}
}

จาก spec ข้างบน ผมสามารถเพิ่ม spec ต่อได้อีกเป็น

public function itShouldNotGetFullAfterEatRiceAndWater()
{
$this->_dog->eat(“rice”);
$this->_dog->eat(“water”);
$this->spec($this->_dog->speech)->should->equal
(“I’m eating water and I need more food grrrr”);
}

เราสามารถเขียนทดสอบการกินน้ำอย่างเดียวก็ได้ อันนี้คิดว่าคงจะพอเดาออกว่าจะเขียน spec ต่อยังไง
หรือแม้กระทั่งการให้มันกินอย่างอื่น ก็ยังสามารถเขียน spec ได้

ปล. ถ้าใครอยากลองทำดูแล้วติดตั้งไม่ผ่านก็ลงความเห็นไว้ละกันครับ ว่าติดตรงไหน จะช่วยแก้ครับ
ปอ. ผมจะลอง implement เหมือนๆ กันใน post นี้ ใน Ruby และ RSpec ครับ แล้วจะแสดงให้ดูว่าถ้าใช้ RSpec แล้ว จะทดสอบพฤติกรรมได้ละเีอียดกว่ายังไง

Test first tools

เอา TDD ก่อน
Java – JUnit
.Net – NUnit
Ruby – Test::Unit
PHP – PHPUnit
Python – PyUnit, py.test
JavaScript – JSUnit

ตามด้วย BDD
Java – JBehave, Instinct หรือ JDave
.Net – NSpec
Ruby- RSpec
PHP – PHPSpec
Python – doctest
JavaScript – JSSpec

ที่เคยใช้จริงๆ คงจะเป็น JUnit, NUnit, Test::Unit และ RSpec ครับ
ฝั่ง ActionScript ของ flash ก็เคยครับ แต่ไม่อยากนับ เพราะแค่ลอง ไม่ได้อยู่กับมันนานๆ
ดูเหมือนภาษาที่ผมควรจะ implement ให้ดูจริงๆ ควรจะเป็น PHP สินะ

ปล. C กับ C++ ผมว่ามันเก่าไป ไม่น่าเอามาพูดถึง

Behavior Driven Development

จริงๆ เรื่องการ test บน Rails เนี่ย ผมกะว่าจะเขียนมานานละ
ช่วงนั้นมี Test Driven Development(TDD) กำลังแรงจาก Extreme programming ไอ้ผมก็เขียน test case บน Rails ก็ปกติดี แต่บังเอิญว่า Behavior Driven Development(BDD) เพิ่งเกิดพอดี เลยยังลังเลว่าจะเขียนเรื่องนี้เลยดีไหม

พอดีเจ้านายผมอยากให้เขียน test ในลักษณะที่รวมสิ่งแวดล้อมรอบด้านด้วย ใน 1 test case ของผมเลยค่อนข้างจะรุงรัง เช่น การ login ก็ตรวจมันตั้งแต่การ validate, login ผ่านหรือเปล่า สมมติว่าผ่าน ต้องจำค่า user เอาไว้แล้ว redirect ไปไหน?? หรืออีก test case นึง กรณีที่ไม่ผ่าน จะ redirect ไปไหน มันก็เลยดูเกินความหมายของคำว่า unit test ไปหน่อย

แล้วก็บังเอิญไปเจอ BDD พอดี ไปเจอ Rspec เข้าให้ ผมกับเจ้านายเลยคิดว่า ไอ้ตัวนี้แหละ ที่เราต้องการ !!! ผมก็เลยเอาไว้ก่อน ให้มันโตมากกว่านี้หน่อย ค่อยเขียน แล้วมันก็สุกงอมพอดี ตอนนี้กระแสที่รุนแรงที่สุดของ Rails คือการทำ BDD ด้วย Rspec นี่แหละ

ทำไมถึงต้องการ ??

BDD มันเกิดมาจากการเรียนรู้จาก TDD

โปรแกรมเมอร์ที่ใช้ TDD เริ่มจะมองเห็นมากกว่าการเป็น unit test คือ เห็นว่าการเขียน test ก่อนเขียน code จะทำให้เรารู้ว่า code ที่จำเป็นมันน่าจะเป็นยังไง หรือเห็น process ของงาน จากนั้นก็เริ่มเห็นความเป็นพฤติกรรม ซึ่งพวกเขาก็เชื่อว่าพฤติกรรมนี่แหละ เป็นหัวใจของ process

ทางทีมที่คิด BDD ขึ้นมา เลยเริ่มผลักดันให้มันเกิดขึ้นมา เพราะเห็นว่าโปรแกรมเมอร์ที่เขียน test คงจะมองเห็นถึงจุดการเป็นพฤติกรรมเนี่ย ไม่เยอะเท่าไหร่ อยากจะให้คนกลุ่มนี้ เข้าถึงแนวความคิดอันนี้

BDD จึงมีจุดประสงค์ให้โปรแกรมเมอร์หรือนักพัฒนา เน้นไปที่การมองว่ามันจะมีพฤติกรรมยังไงมากกว่าการ test ซึ่งจะช่วยให้เข้าถึงตัวงานจริงๆ ได้ตรงและเร็วที่สุด

ซึ่งแบบที่เจ้านายผมให้ผมเขียน test ใน test case นั่นแหละ มันดูเป็นพฤติกรรมตามแนวความคิดของ BDD เลย มันเลยโป๊ะเช้ะ

BDD มันมีพื้นฐานมาจากการดูที่พฤติกรรมเป็นหลัก ถ้าเราตั้งคำถามว่า

Login controller ควรจะทำอะไรได้บ้าง ?

ผมก็จะตอบว่า

มันควรจะ login ได้ปกติ
มันควรจะ login ได้ปกติ และจำไว้(remember me) ด้วย

มันควรจะ login ไม่ได้ เพราะ password ผิดหรือไม่มี username นั้นๆ
มันควรจะ logout ได้

เราจะมามองกันที่พฤติกรรมเป็นหลัก

ถ้าเราตอบได้หมดว่า Login controller ควรจะมีพฤติกรรมอะไรบ้าง นั่นก็น่าจะเป็นสิ่งที่เราต้องการและต้องพัฒนาทั้งหมดแล้ว เห็นภาพรวมหมดทั้งกระบวนการ

ถ้าจะให้กระบวณการ(พฤติกรรม)มันมีความถูกต้อง ก็คงต้อง test มัน(ก่อน)ละครับ สำหรับ Ruby/Rails คงต้อ Rspec นี่แหละครับ ที่ช่วยได้

ที่มา – blog ผมเอง

Test first is not hard

จาก post อันนี้ ผมก็เจอ comment 2 อัน คือ

ความหมายใช่เลย..แต่บางทีใน software requirement อาจจะระบุไม่ละเอียดมาก เลยทำให้พอถึงช่วง UAT ที่ผู้ใช้งานระบบ(ที่ละเอียดหน่อย) เข้ามาทดสอบแล้วบอกว่ายังขาดโน่น ขาดนี่ ทำงานไม่ได้ตาม business ต้องการ ก็ต้องกลับไปเริ่มต้นใหม่อีก

และ

เทสไปเทสมา พบว่ามีหลายอย่างที่ทาง developer ยังทำไม่เรียบร้อยเลยครับ ส่งมาได้ไง

มาดูว่า test first จะช่วยอะไรกับสองปัญหาข้างบนได้บ้าง

เริ่มแรกหลังจากได้ requirement มา programmer อย่างผม ก็ต้องอ่านๆๆ แล้วก็อ่าน แล้วก็สรุป ว่าต้องเขียนอะไรบ้าง(ผมจะเรียกว่า spec ละกัน หรือจะเรียกว่า test case ใน TDD ก็ได้) แล้วก็เขียนลงใน spec file

ตัวอย่างด้านล่างคือ Ruby code ที่ใช้ใน Ruby on Rails นะครับ
เป็นตัวอย่างการเขียน spec ทดสอบ login module ฝั่ง admin

describe AdminController, “authentication:” do
describe “handling POST /admin/login [PASSED]” do
it “should authenticate [PASSED]”
it “should not remember user”
it “should redirect to admin page”
end

describe “handling POST /admin/login [PASSED] with remember me” do
it “should authenticate [PASSED]”
it “should remember user”
it “should redirect to admin page”
end

describe “handling POST /admin/login [FAILED]” do
it “should authenticate [FAILED]”
it “should not remember user”
it “should render login page”
end

describe “handling GET /admin/login” do
it “should not authenticate user”
it “should render login page”
end
end

นี่คือ spec คร่าวๆ ของผม(ยังไม่ได้ implement spec ในส่วนนี้นะครับ) จะเห็นได้ว่ามันแสดงสิ่งที่ควรจะทำในทุกๆ กรณี อยากให้มันทำอะไร ใส่ไปให้มด ถ้า requirement ที่เราได้รับมามีไม่เพียงพอ หรือกำกวม มันจะโผล่มาตั้งแต่ตอนนี้ครับ แล้ว project manager ก็จะไปตีรันฟันแทงกับลูกค้าเอง ในการทำให้มันชัดเจน แล้วก็กลับมาเขียน spec ใหม่อีกที

ปัญหาใน comment ข้อแรก มันจะโผล่มาตั้งแต่ก่อน coding ไม่ต้องรอไปจนถึงการทำ UAT ครับ เริ่มต้นใหม่เหมือนกัน แต่ก็ไม่ต้อง code ให้เสียแรง และไม่ต้อง test ให้เปลืองพลัง

หลังจากนั้น ผมก็ต้อง implement ในส่วนของ spec(testing) กับ business logic และต้อง test ให้ spec ผ่านหมดทุกกรณี ถ้าเราเขียน spec ละเอียด และ test ให้ผ่านหมดทุกกรณี ปัญหาใน comment ข้อที่สอง ก็จะหมดไป(ต้องให้ผ่านหมดทุกกรณีนะครับ และ programmer ก็ห้ามหลอกตัวเองด้วย เหอๆ)

test ผ่านหมด ก็แสดงว่า implement หมดพอดี ต่อไปก็จัดการฝั่งหน้าตาให้มันสวยงาม เราก็ไม่ต้องไปกังวลกับฝั่ง business logic ให้มากความ ถึงต้องกลับไปซ่อม ก็ไม่เหนื่อยมาก

แต่ก็ใช่ว่าเขียน test แล้ว จะไม่มีปัญหาเลย ยังไงๆ ก็ยังมีปัญหาที่คาดไม่ถึงอยู่อีก แต่มันก็ทำให้ฝั่ง tester ทำงานได้สบายขึ้น เวลา test ก็น้อยลง งานก็เสร็จเร็วขึ้น(ถ้าไม่ไปตายตอนเรียนรู้การเขียน test เสียก่อน)

Test first ที่ผมใช้งานอยู่ ไม่ยากเลย 🙂

ปล. ผมใช้ BDD ครับ คำศัพท์อาจจะไม่ค่อยคุ้นเท่าไหร่ ไว้ค่อยๆ เขียนอีกทีในครั้งต่อๆ ไป
ปอ. ผมจะลอง BDD ฝั่ง PHP ละกัน ดูเหมือนจะไม่ค่อยมีใครใช้ Ruby :p
ปฮ. เอ๊ะ ถ้าคนเขียน spec เป็น tester จะเขียนได้ละเอียดกว่า programmer ไหม??

Programmer can test

programmer ก็ช่วย test ได้ครับ

ผมทำงานในทีมเล็กๆ ไม่มีเงิน หรือคนมากพอที่จะไปจ้าง หรือสร้างทีม tester เพราะฉะนั้น โปรแกรมเมอร์นี่แล จะต้องแบ่งเบาภาระการ test ให้กับทีม

สิ่งที่ programmer ช่วยได้ คือการใช้ Test driven development(TDD) เป็นตัวช่วย

สิ่งที่ผมเคยฟาดฟันมาก่อน คือการใช้ unit test ทำการ test source code ในทุกๆ unit ไม่ว่าจะเป็นตัวแปรเอย method(หรือบางคนจะเรียกว่า function)เอย หรือ integration test ที่เขียนยังไงก็ไม่ครอบคลุม จนมีฝรั่งใจดี สร้างสิ่งที่เรียกว่า Behavior driven development(BDD) นี่แหละ ใช่เลย แทนที่เราจะมองให้เป็น unit ทำไมเราไม่มองให้เป็นพฤติกรรม(behavior) ทดสอบที่พฤติกรรมไปเลย มันก็เลยเป็นการรวมกันของ unit test กับ integration test นี่แหละ ใช่เลย!!

แล้ว programmer จะไปเขียน test ตอนไหน ?? หลายๆ คนที่เคยทำ ก็อาจจะบอกว่า ก็เขียน code ไปก่อน แล้วไปเขียน test ทีหลังไง แต่ผมไม่ได้ทำแบบนั้น ผมใช้แนวคิดเรื่อง test first เป็นแนวทาง ก็คือเขียน test ไปก่อนนั่นแหละ แล้วค่อย implement ทีหลัง จริงๆ ต้องบอกว่า test ไป implement ไป มากกว่า

ตอนที่ใช้ Unit test มันจะทำ test first ยากหน่อย เพราะเวลา test มันจะต้อง test จาก code ที่เรา implement จริงๆ แต่พอได้ BDD มาช่วย การทำ test first ก็ดีขึ้น เพราะมันมีสิ่งที่เรียกว่า Mock/Stub เข้ามาช่วย เราเขียน test ได้นานขึ้น แล้วค่อยไป implement ทีเดียว

แน่นอนว่า การทำ test first จะช่วยให้การ test ง่ายขึ้น ดัก runtime error หรือ bug ที่เราคาดไม่ถึงมาก่อนได้มากขึ้น ถ้าเราใช้ unit test มันก็คงจะ test ได้แค่ unit นั้นๆ ที่เราพิจารณา ถึงแม้ integration test จะ test โดยรวมได้ แต่ผมก็ยังว่ามันไม่ครอบคลุมอยู่ดี ถ้าใช้ BDD จะช่วยเรื่องนี้ได้เยอะ เพราะเรามองเป็นพฤติกรรม(เดี๋ยวมาลุยกันตอนถัดไปครับ) ถ้าพฤติกรรมที่เรากำลัง test ผ่าน runtime error ก็จะหายไปเยอะเลย

ฟังดูเหมือนว่าการเขียน test จะเป็นสิ่งดี แต่มันไม่ค่อยสนุกเท่าไหร่ ปัญหามันก็มีบ้างครับ ส่วนใหญ่จะเป็นเรื่องของเวลาครับ เพราะเราจะเสียเวลาไปกับการเขียน test เพิ่มขึ้น แล้วเวลา coding เราจะน้อยลง และต้องเสียเวลาในการเรียนรู้อยู่นานครับ แต่ก็ยังพอมีสิ่งที่ผมเห็นว่าเป็นข้อดีในข้อเสียนี้ ก็คือ เราเสียเวลาในการเขียน code ก็จริง แต่ถ้าเขียน test ให้ครบหมดทุกกรณี(โดยเฉพาะ BDD คือ ทุกกรณีของพฤติกรรมของงานของเรา) เราจะมองเห็นทุก requirement และเป็น flow chart แบบคร่าวๆ

โดยส่วนตัวแล้วผมว่าเสียเวลาสักหน่อย กับการเขียน test เพื่อแลกกับความถูกต้องของงาน ผมว่าคุ้มครับ ทั้งนี้ ยังช่วยให้ tester ทำงานได้ง่ายขึ้นด้วย