หลังจากวุ่นวายอยู่กับการเขียนโค้ดอยู่พักใหญ่ บวกกับการต้องมานั้งแก้บั๊กอีกมากมาย ก็เลยต้องกลับมานั้งคิดว่าเราลืมอะไรไปรึป่าว ทำไมเราถึงเสียเวลามากขนาดนี้ แล้วก็นึกขึ้นได้ตอนสมัยเรียนว่าทำไมเราต้องเรียนวิชา Software Testing

พวกเราส่วนใหญ่ก็จะคิดว่าจะเขียนมันไปทำไมเทส เสียเวลา ในเมื่อเรารู้อยู่แล้วว่าเราจะทำอะไร เขียนโค้ดยังไง…….

แต่ว่าถ้าลองสักเกตดู โปรแกรมเมอน์ที่เก่งๆ ส่วนใหญ่เค้าจะไม่ยอมปล่อยให้ code เค้ามีบั๊กเด็ดขาด ซึ้งไม่ใช่เรื่องง่ายๆที่จะทำได้ เพราะฉะนั้นเค้าจะต้องมีการทำ test ขึ้นมาเพื่อทดสอบระบบ หลังจากนั้งอ่านบทความในเ็บไปสักพักก็ได้ลองดู rails podcast ของ Gregg กับ Jason (ที่นี้) ทีพูดเกียวกับเรื่อง ทำอย่างไรเราถึงจะรักการเทส? ผมจะลองสรุปความคราวๆ ออกมาเป็นหัวข้อด้งนี้

* Why would you test your code? (ทำไม ต้องมานั้งเทสโค้ดตัวเอง)

  1. เราสามารถที่จะเขียนโค้ดไปได้โดยที่ไม่ต้องกังวลว่า ถ้าเราเปลี่ยนแปลงหรือแก้ไขส่วนได้ส่วนนึงของโค้ดแล้วที่อื่นจะมีปัญหา
  2. เค้าว่ากันว่า test case ที่ดี ก็เหมือนกันเรามีคู่มือวิธีการใช้ที่ดี ที่จะทำหน้าที่อธิบายว่าโค้ดเราทำงานอย่างไร แต่บางคนอาจจะเถียงว่า ก็เขียน comment สิจะได้รูว่าโค้ดตรงนี้ทำงานอะไรยังไง แต่ว่า comment ไม่ใช้ตัวอย่างหรือวิธิการใช้ การแสดงตัวอย่างให้เห็นยอมดีกว่าการอธิบายปากเปล่าอยู่แล้ว

* When do you test your code? (เมื่อไหร่ ที่เราควรจะทำเทส)

– คำถามนี้ตอบยากครับ เค้าบอกว่าการเรื่มทำเทสไม่ใช่เรื่องง่ายที่จะใช้เวลาแค่วันเดียวก๊ทำได้ แต่ว่าถ้าเราไม่เริ่มตั้งแต่วันนี้ ยังไงวันหน้าเราก๊ต้องทำอยู่ดี เพราะฉะนั้นเราจะมั่วรออะไรอยู่ (Testing เป็นอะไรที่เข้าใจอยาก แต่ว่าเข้าใจได้!!!)

* How are we going to start? (เราจะมาเริ่มเทสกันอย่างไรดี?)

– Testing is moving target คำนี้บอกเราว่าอะไร มันหมายความว่า ในตอนนี้ไม่มีใครบอกได้ว่าการทำเทสแบบไหนหรือว่าวิธีไหนดีที่สุด เพราะฉะนั้นถ้าจะถามว่าจะใช้วิธีไหนในการเทศหรือว่าทำเทสมันอย่างไร ไม่มีใครสามารถบอกได้นอกจากตัวเอง มันขึ้นอยู่กับว่าแบบไหนที่เหมาะกับตัวคุณและ software ของคุณ

* Test Driven Development (TDD) (อะไรคือ TDD)

– ชื่อมันก็อธิบายตัวเองแล้วนะครับ ก็คือการที่เรามี Test และ Specs เพื่อที่จะเป็นตัวขับเคลื่อนในการเขียนโค้ดของเรา

Steps

  1. เขียน Spec ของโปรแกรม
  2. เขียน Test ของแต่ละ Spec
  3. Code!!!!

ข้อดีของการทำแบบนี้คืออะไร

  1. Think before you code ( ได้คิดก่อนที่จะลงมือเขียนโค้ด ) ผมไม่ได้บอกว่าพวกเราไม่ได้คิดนะครับเวลาเขียนโค้ด แต่ว่าพวกเราทำสองอย่างไปพร้อมๆกัน มันทำให้เราต้องห่วงหน้าพวงหลังอยู่ตอนเวลา
  2. Code is more focus and clear เหมือนกับเวลาเราสร้างบ้านอะครับ ถ้าเราได้สถาปนิกเก่งๆ เขียนแบบมาดีแล้ว บ้านเราก็จะสวยและดี ลองนึกภาพกลับกันว่าถ้าเราไม่มีแบบมาให้ช่างรับเหมาดู เพียงแต่ว่าเราบอกปากป่าวกับช่าง เอ้าเด๋วเติมนั้นนิดเอานั้นออกหน่อย บ้านเรามันจะออกมาเป็นไงครับ ลองนึกกานดู
  3. Know when you finish because all your tests pass เหมือนข้อสองเลยครับ ถ้าเราทำตามแบบแปลนจนเสร็จ บ้านเรา็เสร็จครับ

และนี้ก็คือ idea คราวๆ

200810171226.jpg

picture credit: http://wellington.pm.org

* Behavior Driven Development (BDD) (อะไรคือ BDD)

– เรามาต่อกานเลยจากด้านบนที่เราเริ่มเข้าใจกันแล้วว่า TDD คืออะไร?

แล้ว BDD คืออะไรละ ตามที่ผมเข้านั้นผมคิดว่า มันก็คือ generation รุ่นลูกของ TDD นั้นเอง ซึ้ง BDD ได้ทำการเปลี่ยนแนวคิดเกี่ยวกับการเทสของเดิมที่ว่า Test represent the structure of the code (เทสของ TDD จะบอกว่า function เราควรจะทำอะไรได้บางอย่างไร )

ฺBDD จะเปลี่ยนแนวคิดนั้นเป็น Telling a story with Specifications นั้นก็คือการเล่าเรื่องราวการทำงานของ function ว่ามันทำงานอย่างไร พูดแบบนี้อาจจะยังไม่เห็นภาพ เราจะมาลองยกตัวอย่างกันนะครับ

เช่นเราต้องการที่จะทำ login system

แบบแรก TDD

  • Function for email and password reminder
  • Function for resetting password
  • Function for user role

จะเห็นได้ว่าการ define แบบนี้ เพื่อที่จะสร้าง test case ขึ้นมาเทสฟังก์ชันพวกนี้ จะลงเอ่ยด้วยการเขียนเทสขึ้นมาเพื่อที่จะอธิบายโค้ดตัวเอง ซึ้งทำให้เราไม่สามารถมองภาพกว้างๆ ของ login system ว่าจริงๆ แล้วมันทำงานอย่างไร

ที่นี้เราจะมาลองแบบที่สองกันนั้นก็คือ BDD

แบบสอง BDD (เราจะยกตัวอย่างลักษณะนิสัยเพียง 1 อย่างของ login system มาลองกันนะครับ )

กรณีที่ลืม password

  • should be able to submit email
  • should be sent an email if their email address is valid
  • should be shown notice if their email address is valid
  • should be redirect to the login page if their email address is valid
  • should be sent an error message if their email is invalid

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

ในครั้งหน้าเราจะมาลองทำเทสกันจริงๆ ว่ามันจะสนุกแค่ไหน

* Where’d RSpec come from? (มาว่ากันเรื่องของ RSpec)

* Running Autotest with Growl (Autotest สนุกๆ กับ ruby on rails บน Mac)

ที่มา http://www.railsenvy.com