ในวันที่ Unit test ทำให้ไม่ Agile
หลายๆ สำนักเวลาพูดถึง Technical excellency ก็จะบอกให้เราควรจะทำ Unit test เยอะๆ
ประเด็นนึงที่ผมพบหลักจาก Adopt TDD workflow มาใช้กับตัวเอง คือ เวลาทำ Unit test เนี่ยเราต้องคิดถึง Interface ก่อน แล้วเอา Test ยัดลงไปเพื่อมั่นใจว่ามันยังทำงานตาม Interface นั้นๆ
ข้อดีคือเราได้คิดถึง Interface ก่อน ดังนั้น มันบังคับให้เราคิดมากขึ้น โอกาสได้ Interface ที่ดีอ่านง่ายทำความเข้าใจง่าย ก็มีมากขึ้น
ข้อเสียคือ ถ้าจังหวะที่เรายังไม่ได้มีข้อมูลมากพอที่จะฟันธงว่า Interface ที่ดี หน้าตาควรจะเป็นอย่างไร การโดนบังคับว่าต้องคิดถึงและออกแบบในเวลานี้วินาทีนี้ ก็ทำให้ Interface อาจจะออกมาน่าเกลียดไม่พอ ยังมี Unit Test คอยขัดขวางให้แก้ให้ดีขึ้นยากอีก
Moral จริงๆ ที่ควรพิจารณาคือ เราต้องมี Self-awareness มากพอที่จะพิจารณาได้ว่าจังหวะนี้ในระดับนี้เรามีข้อมูลมากพอที่จะตัดสินใจสร้าง Interface ที่ดีได้หรือยัง
ถ้ามั่นใจแล้ว ก็ Unit test ไปตรงนั้นเลย เหมือนตอกตะปูขันน็อตให้มั่นคง
ถ้าไม่มั่นใจ ก็พยายาม Integration test บนเลเวลที่สูงขึ้น
ถ้าฝืนทำ Unit test ในจังหวะที่เรายังไม่สามารถตัดสินใจได้ว่า Interface ที่ดีหน้าตาต้องเป็นแบบไหน มันก็เหมือนตอกตะปูขันน็อตลงไปในชิ้นส่วนที่ยังออกแบบไม่เสร็จ สุดท้ายก็ต้องถอดอยู่ดี แล้วตะปูกับน็อตเหล่านั้น (Unit test cases) จะเป็นตัวขัดขวางให้เราเปลี่ยนไปสู่สิ่งที่ดีขึ้นยากกว่าเดิมเสียอีก
ถ้าเช่นนั้นแล้วเราจะทำ Unit test ในบริเวณโค้ดส่วนนั้นต่อไป เพื่ออะไรกันนะ
Moral ข้อที่ 1: เราทำ Unit test เพื่อให้ Application คล่องตัว แก้ไขง่าย แก้แล้วมั่นใจว่าไม่พัง เมื่อไหร่ที่ Unit test มันให้ผลตรงข้าม ทำให้เราไปสู่เป้าหมายยากขึ้น ก็ไม่ต้องไปยึดติดกับวิธีการ ยึดกับเป้าหมายน่ะดี แต่ไม่ต้องยึดติดวิธีขนาดนั้น มันเป็นแค่ Guideline เฉยๆ ว่าทำ Unit test แล้ว “น่าจะ” ช่วยให้การแก้ไขระบบโดยไม่ทำพังเป็นไปได้สะดวกขึ้น เมื่อมันไม่ได้ให้ผลนั้นแล้ว หรือเมื่อมีวิธีที่ดีกว่าที่ทำให้ไปสู่ผลลัพธ์ “แก้ไขระบบง่าย” เราก็ควรเปลี่ยนวิธีเลือกวิธีที่ดีกว่าเดิม
Moral ข้อที่ 2: การรู้ว่าเราทำแต่ละอย่างไปเพื่อให้ได้ผลอะไร สำคัญมากๆ การเห็นเป้าหมายว่าเรา Adopt แต่ละ Practice ไปเพื่ออะไร เป็นสิ่งที่จะช่วยให้เราพิจารณาได้อย่างดี
PS. บางครั้งเวลาลอง Practice ใหม่ๆ ที่เขาบอกว่าดี ก็เป็นไปได้ที่เราไม่เข้าใจ Purpose ของมันแต่แค่อยากลอง กรณีนี้ เราก็เดาขึ้นมาเองเลย อย่าทำโดยไม่มี Purpose เช่น สมมติเรา Adopt BDD มา เราก็บอกว่าเราคาดหวัง Bug น้อยลงก็ได้ บอกว่าคาดหวังว่าความไม่เข้าใจระหว่างทีมกับ Stakeholder น้อยลงก็ได้ สุดท้าย ถ้ามันไม่เป็นไปตามที่คาดหวัง ก็แค่ Retro ว่าจะทำต่อเพื่อเป้าหมายอื่นหรือจะเปลี่ยนไม่ทำก็พอ แต่การทำโดยไม่มีผลคาดหวังในใจเนี่ย ผมว่าอันตราย
