Test Coverage หมายถึงว่าตอนที่เรารัน Automated Tests แล้ว โค้ดแต่ละบรรทัดของ Applicaion ถูกรันด้วย Tests เหล่านั้น ซึ่ง 100% จะหมายทุกโค้ดทุกบรรทัดของ Application ของเรานั่นเอง
แล้ว 100% มันดีจริงไหมล่ะ? ผมคิดว่าเราต้องคุยแยกกันในแต่ละมุมที่เรามอง แล้วหลังจากเรามองครบทุกมุมแล้ว ก็ค่อยตัดสินใจเองว่ามันดีจริงไหม เราเชื่อในสิ่งนั้นไหม
ถ้าเรามองว่าโค้ดของเราผ่านการทดสอบด้วย Tests เหล่านั้นหมดนะ เวลาที่ใครจะแก้อะไรก็ตาม เราจะรู้ได้เลยว่าของจะไปพังบน Production ไหม ในมุมนี้ก็อาจจะมองว่าดี ถ้าเรามองว่าเป็นการเสียเวลาโดยใช่เหตุ (ถ้าเราหยิบเอาเฟรมเวิร์คมาใช้) เพราะโค้ดหลาย ๆ บรรทัดมันก็ถูกพิสูจน์ ถูกทดสอบมาแล้วจากทีมที่พัฒนาเฟรมเวิร์คนั้น ๆ ในมุมนี้ก็จะมองว่าไม่ดีเป็นต้น และยังมีอีกหลายมุมมองให้พูดคุยกันอีก
ส่วนสำหรับผมแล้ว การมี 100% Test Coverage มันไม่ได้รับประกันว่า Application ของเรานั้นมี Behavior ที่ตอบโจทย์ธุรกิจ แล้วก็อาจจะมีโอกาสสูงมากที่จะทำให้ทีมพัฒนาไปมองว่า 100% คือ KPI และต้องทำให้ได้ตามนั้น จริงอยู่ถึงแม้ว่าเราจะบอกว่ามันมีรายละเอียดข้างในอีก แต่การที่เราตั้งตัวเลขมา มันก็เหมือนเรากำลังสร้าง System ขึ้นมา ผลที่ตามมาคือ เมื่อทีมอยู่ไปอยู่ใน System นั้นแล้ว พฤติกรรมก็จะเปลี่ยนตามไปโดยไม่รู้ตัว และข้อเสียหนึ่งของการมี 100% Test Coverage จากประสบการณ์ของผมแล้ว มันทำให้ Architecture Design ของเรามันไม่ Flexible ตามธุรกิจ เพราะจะแก้ Architecture ที เราก็ต้องไปตามแก้ Tests ต่าง ๆ เยอะเกินไปหน่อย และสุดท้ายเราจะโดย Tests เป็นตัวกำหนดอนาคตเรา
อ้อ ที่สำคัญอีกอย่างคือ 100% ไม่ได้แปลว่า Software เรามี High Quality นะ อาจจะ Low Quality ด้วยซ้ำ การวัดว่ามี Quality หรือไม่ สำหรับผมแล้วอยู่ที่ User ครับ ว่าเค้ารัก Software ของเราหรือเปล่า :)
กล่าวโดยสรุปคือ ผมไม่เห็นด้วยกับการมีคำว่า 100% Test Coverage และผมจะพยายามเสนอว่าไม่ให้คำนี้มีอยู่ใน Project หรือ Product หรือในทีมที่ผมดูแลอยู่เลย (ในอดีตอาจจะมี)
แล้วควรมีเท่าไหร่ดี? ผมจะให้ตัวเลขนี้ถูกกำหนดอยู่ในบริบทของทีมที่ผมทำงานอยู่ด้วย หรืออาจจะไม่สนใจเลยก็เป็นได้ โดยเราต้องตกลงกันว่าตรงไหนควรจำเป็นต้องมี Tests กันไว้ เพื่อให้มั่นใจว่าโค้ดที่เขียนขึ้นมาต้องทำงานถูกต้องความต้องการของธุรกิจ และตรงไหนไม่จำเป็นต้องมี เพื่อให้เห็นภาพ ลองส่อง Tests ของ Campfire ดู
สุดท้าย เรื่องนี้เราไม่มีความจำเป็นต้องเถียงกันเพื่อเอาชนะ แค่ทำความเข้าใจจุดยืนของแต่ละคนก็พอ เพราะแต่ละคนอาจจะมี Core Belief ที่ต่างกัน OK พอเราเข้าใจกันแล้ว ก็ตัดสินใจ As a Team แล้วไปต่อ (อย่าลืมเขียน Architectural Decision Record (ADR) ไว้ด้วยล่ะ)
แล้ว 100% มันดีจริงไหมล่ะ? ผมคิดว่าเราต้องคุยแยกกันในแต่ละมุมที่เรามอง แล้วหลังจากเรามองครบทุกมุมแล้ว ก็ค่อยตัดสินใจเองว่ามันดีจริงไหม เราเชื่อในสิ่งนั้นไหม
ถ้าเรามองว่าโค้ดของเราผ่านการทดสอบด้วย Tests เหล่านั้นหมดนะ เวลาที่ใครจะแก้อะไรก็ตาม เราจะรู้ได้เลยว่าของจะไปพังบน Production ไหม ในมุมนี้ก็อาจจะมองว่าดี ถ้าเรามองว่าเป็นการเสียเวลาโดยใช่เหตุ (ถ้าเราหยิบเอาเฟรมเวิร์คมาใช้) เพราะโค้ดหลาย ๆ บรรทัดมันก็ถูกพิสูจน์ ถูกทดสอบมาแล้วจากทีมที่พัฒนาเฟรมเวิร์คนั้น ๆ ในมุมนี้ก็จะมองว่าไม่ดีเป็นต้น และยังมีอีกหลายมุมมองให้พูดคุยกันอีก
ส่วนสำหรับผมแล้ว การมี 100% Test Coverage มันไม่ได้รับประกันว่า Application ของเรานั้นมี Behavior ที่ตอบโจทย์ธุรกิจ แล้วก็อาจจะมีโอกาสสูงมากที่จะทำให้ทีมพัฒนาไปมองว่า 100% คือ KPI และต้องทำให้ได้ตามนั้น จริงอยู่ถึงแม้ว่าเราจะบอกว่ามันมีรายละเอียดข้างในอีก แต่การที่เราตั้งตัวเลขมา มันก็เหมือนเรากำลังสร้าง System ขึ้นมา ผลที่ตามมาคือ เมื่อทีมอยู่ไปอยู่ใน System นั้นแล้ว พฤติกรรมก็จะเปลี่ยนตามไปโดยไม่รู้ตัว และข้อเสียหนึ่งของการมี 100% Test Coverage จากประสบการณ์ของผมแล้ว มันทำให้ Architecture Design ของเรามันไม่ Flexible ตามธุรกิจ เพราะจะแก้ Architecture ที เราก็ต้องไปตามแก้ Tests ต่าง ๆ เยอะเกินไปหน่อย และสุดท้ายเราจะโดย Tests เป็นตัวกำหนดอนาคตเรา
อ้อ ที่สำคัญอีกอย่างคือ 100% ไม่ได้แปลว่า Software เรามี High Quality นะ อาจจะ Low Quality ด้วยซ้ำ การวัดว่ามี Quality หรือไม่ สำหรับผมแล้วอยู่ที่ User ครับ ว่าเค้ารัก Software ของเราหรือเปล่า :)
กล่าวโดยสรุปคือ ผมไม่เห็นด้วยกับการมีคำว่า 100% Test Coverage และผมจะพยายามเสนอว่าไม่ให้คำนี้มีอยู่ใน Project หรือ Product หรือในทีมที่ผมดูแลอยู่เลย (ในอดีตอาจจะมี)
แล้วควรมีเท่าไหร่ดี? ผมจะให้ตัวเลขนี้ถูกกำหนดอยู่ในบริบทของทีมที่ผมทำงานอยู่ด้วย หรืออาจจะไม่สนใจเลยก็เป็นได้ โดยเราต้องตกลงกันว่าตรงไหนควรจำเป็นต้องมี Tests กันไว้ เพื่อให้มั่นใจว่าโค้ดที่เขียนขึ้นมาต้องทำงานถูกต้องความต้องการของธุรกิจ และตรงไหนไม่จำเป็นต้องมี เพื่อให้เห็นภาพ ลองส่อง Tests ของ Campfire ดู
สุดท้าย เรื่องนี้เราไม่มีความจำเป็นต้องเถียงกันเพื่อเอาชนะ แค่ทำความเข้าใจจุดยืนของแต่ละคนก็พอ เพราะแต่ละคนอาจจะมี Core Belief ที่ต่างกัน OK พอเราเข้าใจกันแล้ว ก็ตัดสินใจ As a Team แล้วไปต่อ (อย่าลืมเขียน Architectural Decision Record (ADR) ไว้ด้วยล่ะ)
-Kan (กานต์)