เนื้อหาที่จะเล่าเกี่ยวกับ TDD Cycle ต่อจากนี้เป็นการสรุปความเข้าใจจากที่ไปเรียน Test Driven Development กับ Terry Yin มา
การ Test-Driven Development เชื่อว่าหลายคนรู้จักอยู่แล้วว่าคืออะไร
ลองมาทบทวน Basic knowledge ที่เราเคยเข้าใจดีกว่า
TDD Cycle
หลายคนจำมาว่าแค่เราทำตาม step 3 อย่างคือ เขียนเทสให้เฟล, เขียนโค้ดให้เทสผ่าน, refactor โค้ดให้ดีขึ้น แล้วเคยมีใครมาบอกจริง ๆ ไหมครับว่า Test Fail ควรทำอย่างไร เขียนโค้ดให้เทสผ่านทำอย่างไร จริง ๆ กันแน่
Terry อธิบาย Cycle ตัวนี้ได้ออกมาอย่าง make sense มาก เราไปดูกัน
ก่อนไปทำ Test Fails เราจะรู้ได้ยังไงนะว่า เราจะเทสอะไรก่อน มีอะไรที่ต้องเทส เราจะเทสกันถึงตรงไหน แค่ไหนถึงจะครอบคลุม คำตอบก็คือเราต้องทำ problem breakdown จาก requirement ซะก่อน
Problem Breakdown
จังหวะที่เราเขียนเทสที่เฟล จังหวะนั้นเราควรจะรู้อยู่แล้วว่าเราจะเทสอะไร input ค่าอะไร ได้ output เป็นอะไร
Requirement ที่จะมาเขียนโปรแกรมควรจะชัดแบบที่ว่า input มาค่านี้ output ควรจะออกเป็นอะไร
ถัดมาคือเรานำ Requirement มาทำ problem breakdown ดูซิ (ดูจากรูปด้านล่าง)
Requirement เกม Fizz จะเป็นเกมเล่นนับเลข เริ่มจาก 1, 2, .. ถ้าเลขไหนหารด้วย 3 ลงตัว ให้แสดงเป็น Fizz แทน
Natural Sequence
Problem breakdown ที่เราจะใช้ตัวแรกคือ Natural Sequence ก็ดูจากโจทย์ครับว่าการเล่นเกมนี้มันเริ่มจากค่าอะไรได้นะ ซึ่งเกมนี้ก็เริ่มจาก 1
เราก็เลยใช้เทคนิคนี้ในการสร้าง เทสของ input = 1 และเทสของ input = 2
ถ้าเราใช้เทคนิคนี้ต่อ ถัดไปเราก็จะเทส input = 3 สมมติว่าเราเทสถึงตรงนี้เราจะทำอะไรกันต่อดี? ทางเลือกก็จะมี input = 4 และ input = 6 ครับ??
ทำไมถึงเป็น input = 6 ละ?? เพราะว่าเรากำลังใช้เทคนิคที่เรียกว่า Triangulate
Triangulate
เป็นเทคนิคในการจับ pattern ที่เหมือน ๆ กันครับ คือเรารู้อยู่แล้วว่าอะไร หาร 3 ลงตัวใช่ไหม? ก็คือ 3, 6, 9, ..
หมายความว่าเราไม่จำเป็นต้องเขียนทุกเทสที่หาร 3 ลงตัว แต่เราเอา test input จาก pattern นั้นมา 2 ตัว ก็คือ input = 3 และ input = 6 เราก็น่าจะจับ pattern ได้แล้วว่าโค้ดจะออกมาเป็นอะไร เสร็จแล้วเราก็อาจจะ proof ด้วย input = 9 เพื่อความชัวร์ ถ้าเทสออกมาเขียวก็ลบเทส input = 9 ไปเลย
จากโจทย์นี้เราอาจจะใช้ problem breakdown 2 เทคนิคข้างต้นก็พอจะได้ test case ที่จะเขียนแล้ว แต่ถ้าเป็นงานจริงเราอาจจะไปเจอกับ user story เราสามารถนำ user scenario มาทำ problem breakdown ได้
User Scenario
เราสร้างเทสจาก Real User Scenario ได้เช่นเดียวกัน เพราะสิ่งสำคัญคือ เราทำให้คนใช้งานยิ้มได้
format เราไม่จำเป็นต้องเป็น “As a .., I want .., so that ..” จะเป็นอะไรก็ได้ที่ทำให้เรารู้ว่าใครเจอปัญหาอะไรและจะช่วยเขาแก้ปัญหาได้อย่างไร
เมื่อเราทำ problem breakdown ออกมาเราก็จะได้ test case ออกมาเยอะแยะเลยใช่ไหมครับ? เราเอาสิ่งเหล่านี้มาทำเป็น check list ครับ ถ้าอันไหนเทสผ่านถือว่าเราเคลียร์ไปแล้ว ทีนี้เราก็บอกได้แล้วว่างานที่เราทำมี progress ไปถึงไหน
ตอนนี้เราก็พร้อมแล้วสำหรับไปเริ่มเขียนเทสที่เฟล 😂
และก็รู้แล้วว่าเทสที่เฟล ไม่ใช่ว่าเทสอะไรก็ได้ และที่สำคัญคือ เทสไม่ใช่ดวงดาวเมื่อพราวแสง 🥲
