สิ่งที่ต้องทดสอบคือคำถามสำคัญสำหรับทุกทีมแทนที่จะทดสอบ การทดสอบเป็นวิธีปิดท้าย และการเลือกวิธีจัดลำดับความสำคัญของการทดสอบส่วนต่างๆ ในฐานของโค้ดอาจเป็นเรื่องยาก
วิธีจัดลำดับความสำคัญที่ดีที่สุดขึ้นอยู่กับฐานของโค้ดและเป้าหมายของทีม โปรดทราบว่า ถึงแม้จะใช้เวลาและแบนด์วิดท์น้อยในการเขียนการทดสอบเล็กๆ จำนวนมาก (ที่ด้านล่างของพีระมิดทดสอบ เช่น การทดสอบหน่วย) ที่มีความครอบคลุมของโค้ดมาก แต่ไม่จำเป็นว่าจะต้องลดความเสี่ยงโดยรวมต่อโปรเจ็กต์ของคุณ
คุณสามารถเลือกสิ่งที่ต้องการทดสอบก่อนได้ โดยพิจารณาถึงกรณีการใช้งานหลักๆ ของแอปพลิเคชัน เว็บไซต์ หรือไลบรารี ซึ่งอาจทำได้โดยการเขียนการทดสอบคอมโพเนนต์บนส่วนที่สำคัญๆ ของเว็บไซต์ ซึ่งเป็นองค์ประกอบหลักที่ส่งเสริมประสบการณ์ของผู้ใช้ ตัวอย่างเช่น นักพัฒนาเว็บไซต์ที่อนุญาตให้ผู้ใช้อัปโหลดและจัดการข้อมูลตารางเวลาควรจินตนาการและทดสอบวิธีต่างๆ ที่ผู้ใช้อาจดำเนินการเหล่านั้น
อีกวิธีการจัดลำดับความสำคัญคือการรับข้อมูลมากที่สุด หากคุณมีส่วนที่เป็นฐานโหลดที่ "อันตราย" เป็นของเดิม หรือเขียนมาอย่างไม่เหมาะสมในฐานของโค้ด ที่ไม่มีใครในทีมของคุณชอบทำงานเลย การสร้างการทดสอบรอบๆ โค้ดให้มีความสอดคล้องมากขึ้นก่อนที่คุณจะเพิกเฉยต่อโค้ดนั้น หรือเปลี่ยนการออกแบบใหม่เพื่อแก้ไข ลองคิดว่าสิ่งนี้เป็นเหมือนนั่งร้านสำหรับ อาคารที่ถูกประณามไปแล้ว แต่ยังคงเป็นที่ตั้งของศูนย์ข้อมูลของคุณ
มิติข้อมูล
เราได้นำเสนอแนวคิดของพีระมิดทดสอบ หรือรูปทรงการทดสอบอื่น แต่รูปแบบเหล่านี้มักจะนำเสนอการทดสอบเพียงมิติเดียวเท่านั้น คือ เส้นแบ่งตั้งแต่ขอบเขตเล็ก การทดสอบหน่วยอย่างง่าย ไปจนถึงการทดสอบที่ซับซ้อนและวงกว้าง เช่น การทดสอบหน่วยกับการทดสอบการผสานรวมเทียบกับการทดสอบปลายทางถึงปลายทาง
อย่างไรก็ตาม รายการประเภทการทดสอบที่เป็นไปได้บางส่วนจำนวนมากไม่ได้แสดงระดับความซับซ้อน แต่แสดงถึงเป้าหมายหรือเทคนิคการทดสอบแทน ตัวอย่างเช่น การทดสอบแบบ Smoke เป็นการทดสอบในหมวดหมู่ที่แตกต่างกัน ซึ่งอาจเป็นการทดสอบแบบหน่วย การทดสอบแบบต้นทางถึงปลายทาง หรือการทดสอบอื่นๆ แต่มีไว้เพื่อให้ผู้ทดสอบมั่นใจโดยรวมว่าโปรเจ็กต์ที่ทดสอบนั้นอยู่ในสถานะที่ถูกต้อง การทดสอบภาพอาจมีประโยชน์กับ คอมโพเนนต์ขนาดเล็กหรือทั้งเว็บไซต์
ฐานของโค้ดจะมีข้อกำหนดเฉพาะ ตัวอย่างเช่น การปรับโค้ดฐานให้สอดคล้องในฟีเจอร์เดียวเป็นสิ่งที่สำคัญมาก โดยการเขียนการทดสอบประเภทต่างๆ เพื่อให้แน่ใจว่าทำงานได้อย่างถูกต้อง ฟีเจอร์ใหม่ที่ต้องอาศัยการทดสอบมักไม่ใช่คอมโพเนนต์ ฟังก์ชัน หรือวิธีการเพียงอย่างเดียว ซึ่งผลกระทบต่อโปรเจ็กต์อาจเผยแพร่ในวงกว้างและในระดับต่างๆ
ลำดับความสำคัญในการทดสอบอาจขึ้นอยู่กับความต้องการทางธุรกิจของคุณด้วย ระบบทางเทคนิคสูงอาจต้องมีการทดสอบหน่วยที่ซับซ้อนเพื่อยืนยันว่าอัลกอริทึมที่ไม่ซ้ำกันทำงานได้อย่างถูกต้อง ในขณะที่เครื่องมือที่มีการโต้ตอบสูงมีแนวโน้มที่จะเน้นการทดสอบภาพหรือการทดสอบแบบปลายทางถึงปลายทางเพื่อยืนยันว่าอินพุตการสัมผัสที่ซับซ้อนทำให้เกิดการตอบสนองที่ถูกต้อง
แนวทางการทดสอบ
พยายามมุ่งเน้นที่การทดสอบ Use Case ของ Codebase โดยไม่คำนึงถึงขนาด ลองนึกภาพวิธีที่ผู้ใช้อาจใช้ส่วนใดก็ได้ในโปรเจ็กต์ของคุณ ซึ่งอาจเป็นคอมโพเนนต์เดียว ฟังก์ชันระดับล่าง หรือกรณีการใช้งานระดับสูงตั้งแต่ต้นจนจบ (นอกจากนี้ ยังเผยให้เห็นถึงข้อบกพร่องในนามธรรมของคุณไม่ว่าในระดับใด หากคุณพบว่าการทดสอบโต้ตอบกับโค้ดได้ไม่สมบูรณ์แบบอยู่ระหว่างการทดสอบ)
การทดสอบแต่ละกรณีจะต้องมีเป้าหมายที่ชัดเจน การทดสอบแบบ "รวมทั้งหมด" ขนาดใหญ่อาจยุ่งยาก เหมือนกับในโค้ดที่ไม่ใช่การทดสอบ
นอกเหนือจากการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ
การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) คือแนวทางที่ไม่เหมือนใครในการทดสอบ คือแบบเฉพาะตัวในการปรับขนาดหรือประเภท โดยเกี่ยวข้องกับการเขียนการทดสอบที่ตั้งใจให้ล้มเหลวอย่างน้อยที่สุด วิธีนี้สามารถใช้กับทั้งการทดสอบด้วยตนเองและการทดสอบอัตโนมัติ โดยอธิบายเป้าหมายที่ต้องการบรรลุผล ดูว่าโซลูชันหรือโค้ดปัจจุบันใดขาดหายไป และใช้การทดสอบที่ไม่ผ่านเป็นแนวทางในการแก้ปัญหา
แน่นอนว่าการทดสอบสถานการณ์ที่เป็นไปได้ทั้งหมดในแอปพลิเคชันหรือองค์ประกอบสมมติได้ไม่มีประโยชน์ก่อนที่จะเริ่มสร้าง TDD มีโครงสร้างและมีประโยชน์เนื่องจากฐานของโค้ดซับซ้อนยิ่งขึ้น
TDD เป็นแนวทางปฏิบัติที่ดีในการแก้ไขข้อบกพร่อง หากคุณสามารถจัดทำกรณีข้อบกพร่องที่ทำให้เกิดปัญหาซ้ำได้ คุณก็สามารถทำการทดสอบอัตโนมัติที่อาจล้มเหลวในครั้งแรกได้ เมื่อแก้ไขข้อบกพร่องแล้ว การทดสอบจะผ่านเพื่อให้คุณพิจารณาว่าการแก้ไขสำเร็จหรือไม่หากไม่มีการยืนยันด้วยตนเอง
ทึบกับกล่องใส
ซึ่งหมายถึงวิธีที่คุณทดสอบส่วนใดๆ ของระบบของคุณ ถ้าตารางไม่ชัดเจน คุณจะมองไม่เห็นด้านใน เช่น เมื่อใช้อินเทอร์เฟซสาธารณะของคลาสแทนที่จะตรวจสอบภายใน
คุณควรเริ่มต้นด้วยการทดสอบกล่องทึบแสงเพื่อออกแบบการทดสอบตามลักษณะการใช้งานคอมโพเนนต์ และไม่รบกวนการทำงานของระบบภายใน แต่หากไม่มีเหตุผลที่เฉพาะเจาะจง หากคุณใช้เพียงอินเทอร์เฟซ "สาธารณะ" ของเส้นทางโค้ด (ไม่จำเป็นต้องเปิดเผยต่อผู้ใช้ แต่อาจแชร์กับส่วนอื่นๆ ของโค้ด) คุณสามารถเปลี่ยนโครงสร้างภายในโค้ดและปรับปรุงโค้ดดังกล่าวได้อย่างอิสระ โดยทราบว่าการทดสอบจะตรวจพบการเปลี่ยนแปลงได้
วิธีหนึ่งที่จะแปลงโค้ด "ล้างกล่อง" ให้ทึบแสงมากขึ้นคือการแนะนำองค์ประกอบที่กำหนดค่าได้ เช่น นามธรรมสำหรับทรัพยากร Dependency ของโค้ด หรือการเรียกกลับเพื่อสังเกตสถานะ แทนที่จะใช้สถานะเชื่อมโยงอยู่กับระบบอื่นๆ อย่างแน่นหนา ซึ่งจะทำให้โค้ดแยกส่วนกันมากขึ้นและให้คุณระบุเวอร์ชัน "ทดสอบ" ได้ หรือคุณอาจจำลองตำแหน่งที่โค้ดโต้ตอบกับระบบอื่นๆ ก็ได้