ในการพัฒนา 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 หรือไม่ ?
ถ้าใช่ก็ปรับปรุงเถอะนะ จะได้ไม่เป็นภาระต่อไป
แต่ถ้าใครยังไม่เขียนก็กรุณาเขียนด้วยนะ
