ทดลอง BDD

posted on 04 Mar 2008 16:01 by wonam in softdev

หลังจากตามอ่านเรื่อง Behavioral-Driven Development (BDD) มานาน วันนี้ได้ลองเดินตามรอยเท้าคุณ Punneng เสียที

เกริ่นสักนิดก่อน หลายคนคงรู้จัก unit test ซึ่งก็คือการทดสอบ unit (หรือส่วนย่อยของระบบซอฟต์แวร์ของเรา) โดยเป็นอิสระจากหน่วยย่อยอื่น ๆ

วิธีการทดสอบทั่วไป ก็อาจใช้ mock หรือ stub มากั้น unit จากส่วนอื่น ๆ ที่มันขึ้นอยู่ เพื่อทำให้ unit เป็นอิสระจะได้ทดสอบได้ง่าย

ทีนี้ เวลาเราทำ unit test ก็มักจะมีคำถามว่า แล้วจะทดสอบอะไรดี? ยิ่งถ้าคนที่ใช้การทดสอบเพื่อขับเคลื่อนการพัฒนา (test-driven development) แล้ว คำถามนี้เป็นคำถามที่สำคัญมาก

หลักการโดยทั่วไปก็คือ เราจะพัฒนาตาม spec ทีนี้ ถ้าเราใช้การทดสอบมาขับเคลื่อนการพัฒนา เราก็ควรจะทดสอบไปตาม spec ทีนี้เราจะจัดการอย่างไรให้การทดสอบนั้นครบถ้วนตาม spec หรือถ้ามองกลับไปอีกทางก็อาจจะได้ข้อสรุปว่า ก็ให้การทดสอบกับการเขียน spec มันกลายเป็นเรื่องเดียวกันไปเสียเลย!

เท่าที่ผมได้ลอง BDD มันก็ไม่ต่างจาก Unit Test มากนัก ถ้าเราเขียน Unit Test โดยอิงกับพฤติกรรม (หรือ spec) ของ unit อยู่แล้ว

สิ่งที่ BDD มีเพิ่มจาก unit test ทั่วไปก็คือ... ขออุบไว้ก่อน... มาดู output จากการรัน test (หรือ spec) กันก่อน

A grader engine, when grading a submission
- should grade normal submission
- should produce error message when submission cannot compile
- should produce timeout error when submission runs forever
- should produce timeout error correctly when submission runs 
slower than expected in less than a second
- should produce runtime error when submission uses too much 
static memory
- should not allow submission to allocate too much dynamic memory
A grader engine, when working with task queue - should just return nil when there is no submission - should grade oldest task in queue
Finished in 15.147147 seconds
8 examples, 0 failures

 

แต่ละ "should...." เนี่ยะ คือแต่ละ test case ที่ผมใส่ลงไป หรือในภาษาของพวก BDD ก็จะเรียกว่า example ที่ระบุพฤติกรรมของ unit นั่นเอง (ผมขอเรียกว่า test ไปก่อน เพราะว่าจะได้เข้าใจง่าย)

เวลาเราเขียนส่วน test นี่เราก็ต้องตั้งชื่อให้เวลามันพิมพ์ออกมาแล้ว อ่านได้เป็น spec แบบข้างต้น ทีนี้รูปแบบการบังคับแถมส่งเสริมนี้เอง ทำให้เวลาเราจะคิด test case อะไร ก็ต้องคิดให้มากหน่อย ไม่ใช่เอาแค่ test_grader_correct1, test_grader_correct2 อีกต่อไป

นอกจากนี้เวลาเขียน test ออกมาแล้ว เราก็เห็นด้วยว่าเรา test ไปถึงไหนแล้ว

ยิ่งไปกว่านั้น ในกรณีที่เราทำ test-driven มันก็ทำให้เห็นด้วยว่านี่เรากำลังดู spec ไปถึงไหนด้วย

ถ้าสวมวิญญาณพวก agile คงบอกว่า code คือ document (อันนี้จะตรงกันข้ามกับพวกสาย cmmi เพราะสายนั้นกะว่าจะเขียน document แล้ว generate ออกมาให้เป็น code แทน)

เอาเข้าจริง ๆ นี่แหล่ะครับ คือสิ่งที่ผมคิดว่า BDD เพิ่มขึ้นมาจาก unit test ทั่วไป ซึ่งก็คือ: เป้าหมายที่ชัดเจนในการขับเคลื่อน

นอกจากนี้ สิ่งที่ framework ที่ผมใช้ (rspec) และ framework อื่น ๆ น่าจะมีเช่นเดียวกัน ก็คือ เครื่องมือประกอบที่ทำให้การเขียนดังกล่าวเป็นไปได้ง่าย สะดวก แล้วก็อ่านรู้เรื่องอีกต่างหาก

ทำไปทำมา มันทำให้การเขียน test ง่ายขึ้นแล้วก็เห็นผลชัดเจน

ถ้าใครสนใจลองทดลอง framework ที่มีในภาษาที่ตัวเองชอบก็ได้ครับ

ผมลองใน rspec ด้วยความสนุก ผมก็แก้ testcase ไปแก้มา (จนไม่ได้เขียนอะไรจริงจัง ยกเว้นนั่งแก้บั๊ก) ถ้าใครอยากรู้ว่าเขียน ruby แล้วมันสนุกอย่างไร ก็ลองอ่าน code ด้านล่างนะครับ

Comment

Comment:

Tweet

พี่ใหม่(cblue) เคยมาชวนทำภาษาไทยกับ rspec เหมือนกันครับ

คงต้องเคลียร์ตัวเองให้ว่างก่อนครับ คงจะได้กระโดดมาทำบ้าง

#4 By PunNeng (58.8.115.3) on 2008-03-09 22:02

โอ้ว เจ๋งๆ

#3 By wonam on 2008-03-07 11:12

อ้าว link ไม่ได้ทำอย่างนั้นหรอกหรอ หน้าแตกเลย : P (เล่นจริง เจ็บจริงกับเค้าด้วย)

http://www.narisa.com/forums/index.php?showtopic=22293&st=0

ปล. Groovy นะครับ

#2 By deans4j (124.120.142.53) on 2008-03-07 08:04

สนใจลอง tspec บ้างมั้ยครับ

จุดเด่นคือ ภาษาไทย เพื่อ คนไทย เล่นจริง เจ็บจริง : P

[url=http://www.narisa.com/forums/index.php?showtopic=22293&st=0&#entry108412]tspec ครับ [/url]

#1 By deans4j (124.120.142.53) on 2008-03-07 08:02