จาก 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 ไหม??