ว่าด้วยเรื่อง Spaghetti Pattern ในชุดการทดสอบ

ในการพัฒนา software นั้นเรามักจะได้ยินคำว่า Spaghetti code บ่อยมาก ๆ ซึ่งก่อให้เกิดปัญหาตามมามากมาย ส่งผลให้การดูแลรักษาระบบเป็นเรื่องที่ยาก และ ต้องใช้ค่าใช้จ่ายที่สูงมาก ๆ โดยปัญหานี้ก็ยังพบเจอในชุดการทดสอบอีกด้วย เนื่องจากทีมพัฒนาไม่สนใจ เนื่องจากทีมพัฒนาไม่ใส่ใจ เนื่องจากทีมพัฒนาไม่ทำการปรับปรุงให้ดีขึ้นอย่างสม่ำเสมอ หรืออาจจะไม่รู้ด้วยว่า สิ่งที่ทำลงไปนั้นมันก่อให้เกิดปัญหาอย่างไร ดังนั้นสิ่งที่ควรทำก็คือ ปรับปรุงชุดการทดสอบอย่างสม่ำเสมอ ทั้งการปรับปรุงโครงสร้าง ทั้งการลบชุดการทดสอบที่ไม่ได้ใช้งาน ทั้งเวลาในการทดสอบที่ต้องลดลง รวมทั้งปรับปรุงเรื่องความรู้ความสามารถอีกด้วย

คำถามคือ ปัจจุบันเราทำการปรับปรุงกันบ้างหรือไม่ ? หรือเพียงทำให้มันเสร็จไปวัน ๆ เท่านั้นเอง !!

ในบทความนี้จะอธิบายเกี่ยวกับรูปแบบของ Spaghetti Pattern ในชุดการทดสอบ

ว่าเป็นอย่างไรบ้าง ? ว่ามีข้อดีอะไรบ้าง ? ว่ามีข้อเสียอะไรบ้าง ? ในการพัฒนาที่เขียนชุดการทดสอบจะพบว่า จำนวนของชุดการทดสอบจะมากขึ้นเรื่อย ๆ ที่สำคัญมักจะมีรูปแบบ code ที่เรียกว่า anti-pattern มากขึ้นเช่นกัน โดย anti-pattern นั้นคือ รูปแบบของ code ที่เจอเป็นปกติ เป็นวิธีการที่ทำงานได้ เหมาะมาก ๆ พัฒนาได้เร็วมาก ๆ ในขณะนั้น !! แต่เมื่อดูให้ดีพบว่า ทำให้เกิดผลกระทบมากมาย หรือทำให้ชุดการทดสอบพังง่ายมาก ๆ

แต่ถ้าถามว่า มีวิธีการแก้ไขปัญหา หรือ สิ่งที่ดีกว่าหรือไม่ ? ตอบได้เลยว่า มีสิ แต่ ... นักพัฒนาส่วนใหญ่จะบอกว่า ไม่ ไม่มีเวลา เดี๋ยวค่อยกลับทำทีหลัง ไว้มีเวลาค่อยมาแก้ไข ทำให้เสร็จก่อนนะ

สุดท้ายคือ ไม่เคยกลับมาแก้ไขเลย (Later is Never) นี่แหละคือ anti-pattern ที่เกิดขึ้น ซึ่งเป็นแนวคิด และ วินัยของนักพัฒนาที่ไม่ดีเลยนะ ผมคิดว่า นักพัฒนาส่วนใหญ่ไม่เป็นแบบนี้กันหรอกนะ

โดยที่ anti-pattern มีมากมายเช่น

• Spaghetti Pattern
• สำหรับ UI testing การเลือก locator ก็สำคัญ
• ใช้ XPath และ CSS selector มาก ๆ ก็แย่ เพราะว่าเปลี่ยน UI ทีก็พังที !!
• การใช้ absolute path เยอะ ๆ ก็ทรมาน
• ถ้าต้องทดสอบชุดการทดสอบแบบ sequential หรือ เรียงลำดับกันก็ไม่น่าจะใช่ เพราะว่า ช้ามาก ๆ
• แต่ละ test case ต้องทำงานต่อเนื่องกันเสมอ
• Code ของการทดสอบแต่ละ test case เยอะ ๆ หรือเอาทุกอย่างมากองรวมกัน น่าจะไม่ใช่แนวทางที่ดี

คำถามคือ ถ้าใครเขียนชุดการทดสอบแล้วเป็นลักษณะนี้ บอกได้เลยว่า ต้องเจอปัญหามากมายอย่างแน่นอน สุดท้ายอาจจะทำให้ท้อใจท้อกาย จนทำให้เลิกเขียนเลิกใช้ไปในที่สุด แล้วก็จะบอกว่า มันไม่ work นะ !!

คำถามคือ สิ่งที่บอกว่าไม่ work มันมาจากไหน ? ลองตอบกันดูนะ

มาดูรายละเอียดของ Spaghetti Pattern กันบ้าง

หลัก ๆ มาจากขาดประสบการณ์ในการออกแบบ พูดง่ายว่า ออกแบบได้แย่มาก ๆ ทั้งในแง่ architecture ของระบบ ทั้งในแง่โครงสร้างของ code ทั้งในแง่โครงสร้างของการทดสอบ ตัวอย่างเช่น ชุดการทดสอบมีขนาดใหญ่ ชุดการทดสอบนัวเนีย พัวพันกันไปหมด ชุดการทดสอบหนึ่งต้องรอผลจากการทดสอบหนึ่ง ๆ ชุดการทดสอบซ้ำ ๆ ในเรื่องเดิม ๆ ชุดการทดสอบแก้ไขได้ยากมาก ๆ ชุดการทดสอบไม่ได้อธิบาย business flow อะไรเลย ชุดการทดสอบไม่สามารถทดสอบซ้ำได้ มีตัวแปรระดับ global ในการทดสอบ ซึ่งแต่ละการทดสอบต้องใช้งานร่วมกัน !!

ถ้าระบบงานทำงานช้า ก็แก้ไขชุดการทดสอบให้รอไปสิ !! แบบนี้เจอเยอะมาก ๆ

อธิบายการทำงานยากมาก ๆ ไป ๆ มา ๆ ต้องมานั่ง debug ชุดการทดสอบเหล่านั้นอีก !!

นี่ก็คือรูปแบบคร่าว ๆ ของ Spaghetti นะ มีใครตกอยู่ในสถานการณ์แบบนี้บ้าง ? หรือว่ากำลังลงมือสร้างขึ้นมา ?

แต่ว่ามันก็มีข้อดีนะ ไม่เช่นนั้นคงไม่ทำกัน !!

สามารถเริ่มต้นทำได้เร็ว นั่นคือ Make it work ซึ่งดีมาก ๆ ถ้ามันทำงานได้แล้ว สิ่งที่ต้องตามมาเสมอก็คือ Make it right และ Make it fast แต่พบว่ามักจะไม่ทำกันนะสิ เพราะว่าของมัน work แล้ว ดังนั้นจึงไปทำงานอื่นต่อเถอะนะ !! ช่วยทำให้เขียน code น้อยลง เนื่องจากชุดการทดสอบอื่น ๆ ทำไว้แล้ว ดังนั้น เราก็แค่รอผลการทำงานจากชุดการทดสอบอื่นก่อน จากนั้นจึงนำผลมาใช้งานต่อไป !! ดูเหมือนจะดีนะ เนื่องจากมันคือการ reuse ของที่มี ลดจำนวน duplication code ลงไปมาก ๆ แต่กลับทำให้ชุดการทดสอบผูกติดกันแน่นมาก ๆ ส่งผลให้การทดสอบช้า เนื่องจากต้องรอ ที่สำคัญทดสอบแบบ parallel ไม่ได้อีก !!

สุดท้ายแล้ว ลองกลับไปดูกันหน่อยว่า ชุดการทดสอบที่เขียนขึ้นมาเป็นอย่างไรกันบ้าง ?

มีลักษณะตาม Spaghetti Pattern หรือไม่ ? ถ้าใช่ก็ปรับปรุงเถอะนะ จะได้ไม่เป็นภาระต่อไป แต่ถ้าใครยังไม่เขียนก็กรุณาเขียนด้วยนะ