การทดสอบหน่วย

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

ในการเขียนโปรแกรมคอมพิวเตอร์ การทดสอบหน่วยเป็น วิธี การทดสอบซอฟต์แวร์โดยที่แต่ละหน่วยของซอร์สโค้ด — ชุดของโมดูลโปรแกรมคอมพิวเตอร์ตั้งแต่หนึ่งโมดูล ขึ้น ไปพร้อมกับข้อมูลการควบคุมที่เกี่ยวข้อง ขั้นตอนการใช้งานและขั้นตอนการปฏิบัติงาน—ได้รับการทดสอบเพื่อพิจารณาว่าเหมาะสมสำหรับการใช้งานหรือไม่ . [1]

คำอธิบาย

การทดสอบหน่วยมักจะเป็นการทดสอบอัตโนมัติที่เขียนและเรียกใช้โดยนักพัฒนาซอฟต์แวร์เพื่อให้แน่ใจว่าส่วนของแอปพลิเคชัน (เรียกว่า "หน่วย") ตรงตามการออกแบบและทำงานตามที่ตั้งใจไว้ [2]ในการเขียนโปรแกรมเชิงขั้นตอนยูนิตอาจเป็นทั้งโมดูล แต่โดยทั่วไปแล้วจะเป็นฟังก์ชันหรือขั้นตอนแต่ละรายการมากกว่า ในการเขียนโปรแกรมเชิงวัตถุหน่วยมักจะเป็นอินเทอร์เฟซทั้งหมด เช่น คลาส หรือเมธอดแต่ละรายการ [3]โดยการเขียนการทดสอบเป็นลำดับแรกสำหรับหน่วยทดสอบที่เล็กที่สุด จากนั้นพฤติกรรมผสมระหว่างหน่วยนั้น เราสามารถสร้างการทดสอบที่ครอบคลุมสำหรับการใช้งานที่ซับซ้อนได้ [2]

เพื่อแยกปัญหาที่อาจเกิดขึ้น แต่ละกรณีทดสอบควรได้รับการทดสอบอย่างอิสระ สามารถใช้ แทน วิธีการ แทนต้นขั้ววัตถุจำลอง[4] ของ ปลอมและสายรัดทดสอบเพื่อช่วยในการทดสอบโมดูลในการแยก

ในระหว่างการพัฒนา ผู้พัฒนาซอฟต์แวร์อาจกำหนดเกณฑ์หรือผลลัพธ์ที่ทราบดีว่าดีในการทดสอบเพื่อตรวจสอบความถูกต้องของหน่วย ระหว่างการดำเนินการกรณีทดสอบ เฟรมเวิร์กบันทึกการทดสอบที่ล้มเหลวตามเกณฑ์ใดๆ และรายงานในบทสรุป สำหรับสิ่งนี้ วิธีที่ใช้บ่อยที่สุดคือการทดสอบ - ฟังก์ชัน - ค่าที่คาดหวัง

การเขียนและการบำรุงรักษาหน่วยการทดสอบสามารถทำได้เร็วขึ้นโดยใช้ การทดสอบ แบบกำหนดพารามิเตอร์ สิ่งเหล่านี้ช่วยให้ดำเนินการทดสอบหนึ่งครั้งได้หลายครั้งด้วยชุดอินพุตที่ต่างกัน ซึ่งช่วยลดความซ้ำซ้อนของรหัสทดสอบ ซึ่งแตกต่างจากการทดสอบหน่วยแบบเดิม ซึ่งมักจะเป็นวิธีปิดและการทดสอบเงื่อนไขที่ไม่แปรเปลี่ยน การทดสอบแบบกำหนดพารามิเตอร์จะใช้ชุดพารามิเตอร์ใดๆ การทดสอบแบบกำหนดพารามิเตอร์รองรับโดยTestNG , JUnitและ .Net ที่เทียบเท่า XUnit. พารามิเตอร์ที่เหมาะสมสำหรับการทดสอบหน่วยอาจจัดหาด้วยตนเองหรือในบางกรณีอาจสร้างโดยอัตโนมัติโดยกรอบการทดสอบ ในช่วงไม่กี่ปีที่ผ่านมาได้มีการเพิ่มการสนับสนุนสำหรับการเขียนการทดสอบที่มีประสิทธิภาพมากขึ้น (หน่วย) โดยใช้ประโยชน์จากแนวคิดของทฤษฎี กรณีทดสอบที่ดำเนินการขั้นตอนเดียวกัน แต่ใช้ข้อมูลการทดสอบที่สร้างขึ้นขณะใช้งานจริง ซึ่งแตกต่างจากการทดสอบแบบกำหนดพารามิเตอร์ปกติที่ใช้ขั้นตอนการดำเนินการเดียวกันกับชุดอินพุต ที่กำหนดไว้ล่วงหน้า [5] [6] [7]

ข้อดี

เป้าหมายของการทดสอบหน่วยคือการแยกแต่ละส่วนของโปรแกรมและแสดงว่าแต่ละส่วนถูกต้อง [1] การทดสอบหน่วยให้ สัญญา ที่ เข้มงวดและเป็นลายลักษณ์อักษรซึ่งชิ้นส่วนของรหัสต้องปฏิบัติตาม ส่งผลให้มีประโยชน์หลายประการ

การทดสอบหน่วยพบปัญหาในช่วงต้นของวงจรการพัฒนา ซึ่งรวมถึงข้อบกพร่องในการใช้งานโปรแกรมเมอร์และข้อบกพร่องหรือส่วนที่ขาดหายไปของข้อกำหนดสำหรับหน่วย ขั้นตอนการเขียนชุดการทดสอบอย่างละเอียดบีบให้ผู้เขียนคิดผ่านปัจจัยนำเข้า ผลลัพธ์ เงื่อนไขข้อผิดพลาด และด้วยเหตุนี้จึงกำหนดพฤติกรรมที่ต้องการของหน่วยได้ชัดเจนยิ่งขึ้น ค่าใช้จ่ายในการค้นหาจุดบกพร่องก่อนเริ่มการเข้ารหัสหรือเมื่อเขียนรหัสครั้งแรกนั้นต่ำกว่าค่าใช้จ่ายในการตรวจจับ ระบุ และแก้ไขข้อผิดพลาดในภายหลังอย่างมาก ข้อบกพร่องในโค้ดที่เผยแพร่อาจทำให้เกิดปัญหาราคาแพงสำหรับผู้ใช้ซอฟต์แวร์ [8] [9] [10]รหัสอาจเป็นไปไม่ได้หรือยากต่อการทดสอบหน่วยหากเขียนไม่ดี ดังนั้นการทดสอบหน่วยจึงสามารถบังคับให้นักพัฒนาจัดโครงสร้างฟังก์ชันและอ็อบเจ็กต์ด้วยวิธีที่ดีกว่า

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

การทดสอบหน่วยช่วยให้โปรแกรมเมอร์สร้างโค้ดใหม่หรืออัปเกรดไลบรารีระบบในภายหลัง และตรวจสอบให้แน่ใจว่าโมดูลยังคงทำงานอย่างถูกต้อง (เช่น ในการทดสอบการถดถอย ) ขั้นตอนคือการเขียนกรณีทดสอบสำหรับฟังก์ชันและวิธีการ ทั้งหมด เพื่อให้เมื่อใดก็ตามที่การเปลี่ยนแปลงทำให้เกิดข้อผิดพลาด จะสามารถระบุได้อย่างรวดเร็ว การทดสอบหน่วยตรวจพบการเปลี่ยนแปลงที่อาจทำลาย สัญญา การ ออกแบบ

การทดสอบหน่วยอาจลดความไม่แน่นอนในหน่วยต่างๆ ลง และสามารถนำมาใช้ในแนวทางรูปแบบการทดสอบ จาก ล่างขึ้น บน การทดสอบส่วนต่างๆ ของโปรแกรมก่อนแล้วจึงทดสอบผลรวมของชิ้นส่วนการทดสอบการรวมจะง่ายขึ้นมาก [ ต้องการการอ้างอิง ]

การทดสอบหน่วยจัดเตรียมเอกสารเกี่ยวกับการใช้ชีวิตของระบบ นักพัฒนาที่ต้องการเรียนรู้ว่ายูนิตมีฟังก์ชันการทำงานใดบ้าง และใช้งานอย่างไร สามารถดูการทดสอบหน่วยเพื่อทำความเข้าใจพื้นฐานเกี่ยวกับอินเทอร์เฟซของยูนิต ( API ) [ ต้องการการอ้างอิง ]

กรณีทดสอบ ของ หน่วยรวบรวมลักษณะที่มีความสำคัญต่อความสำเร็จของหน่วย ลักษณะเหล่านี้สามารถบ่งบอกถึงการใช้หน่วยที่เหมาะสม/ไม่เหมาะสม ตลอดจนพฤติกรรมเชิงลบที่หน่วยจะดักไว้ กรณีทดสอบหน่วย ในตัวของมันเอง บันทึกคุณลักษณะที่สำคัญเหล่านี้ แม้ว่าสภาพแวดล้อมการพัฒนาซอฟต์แวร์จำนวนมากไม่ได้อาศัยเพียงรหัสในการจัดทำเอกสารผลิตภัณฑ์ในการพัฒนา [ ต้องการการอ้างอิง ]

เมื่อซอฟต์แวร์ได้รับการพัฒนาโดยใช้แนวทางที่ขับเคลื่อนด้วยการทดสอบ การผสมผสานระหว่างการเขียนการทดสอบหน่วยเพื่อระบุอินเทอร์เฟซพร้อมกิจกรรมการปรับโครงสร้างใหม่ที่ดำเนินการหลังจากการทดสอบผ่าน อาจใช้แทนการออกแบบที่เป็นทางการ การทดสอบแต่ละหน่วยสามารถมองว่าเป็นองค์ประกอบการออกแบบที่ระบุคลาส เมธอด และพฤติกรรมที่สังเกตได้ [ ต้องการการอ้างอิง ]

ข้อจำกัดและข้อเสีย

การทดสอบจะไม่ตรวจจับทุกข้อผิดพลาดในโปรแกรม เนื่องจากไม่สามารถประเมินทุกเส้นทางการดำเนินการในโปรแกรมใดๆ ได้ ยกเว้นโปรแกรมที่ไม่สำคัญที่สุด ปัญหานี้เป็น superset ของปัญหาการหยุดชะงักซึ่งไม่สามารถตัดสินใจได้ เช่นเดียวกับการทดสอบหน่วย นอกจากนี้ การทดสอบหน่วยตามคำจำกัดความจะทดสอบการทำงานของหน่วยเท่านั้น ดังนั้น จะไม่ตรวจจับข้อผิดพลาดในการผสานรวมหรือข้อผิดพลาดระดับระบบที่กว้างขึ้น (เช่น ฟังก์ชันที่ดำเนินการในหลายหน่วย หรือพื้นที่ทดสอบที่ไม่ทำงาน เช่นประสิทธิภาพ ) การทดสอบหน่วยควรทำร่วมกับการทดสอบซอฟต์แวร์ อื่นๆกิจกรรม เนื่องจากสามารถแสดงเฉพาะการมีอยู่หรือไม่มีข้อผิดพลาดเฉพาะ พวกเขาไม่สามารถพิสูจน์ได้ว่าไม่มีข้อผิดพลาดอย่างสมบูรณ์ เพื่อรับประกันพฤติกรรมที่ถูกต้องสำหรับทุกเส้นทางการดำเนินการและทุกอินพุตที่เป็นไปได้ และเพื่อให้แน่ใจว่าไม่มีข้อผิดพลาด ต้องใช้เทคนิคอื่นๆ กล่าวคือ การใช้วิธีการที่เป็นทางการเพื่อพิสูจน์ว่าส่วนประกอบซอฟต์แวร์ไม่มีพฤติกรรมที่ไม่คาดคิด [ ต้องการการอ้างอิง ]

ลำดับชั้นที่ซับซ้อนของการทดสอบหน่วยไม่เท่ากับการทดสอบการรวม การผสานรวมกับชุดอุปกรณ์ต่อพ่วงควรรวมอยู่ในการทดสอบการประกอบ แต่ไม่รวมอยู่ในการทดสอบหน่วย [ ต้องการอ้างอิง ]การทดสอบการบูรณาการโดยทั่วไปยังคงอาศัยการทดสอบของมนุษย์ด้วยตนเอง เป็นอย่าง มาก การทดสอบระดับสูงหรือขอบเขตทั่วโลกอาจทำให้ระบบอัตโนมัติทำได้ยาก ดังนั้นการทดสอบด้วยตนเองมักจะรวดเร็วและถูกกว่า [ ต้องการการอ้างอิง ]

การทดสอบซอฟต์แวร์เป็นปัญหาเชิงผสมผสาน ตัวอย่างเช่น ทุกคำสั่งการตัดสินใจแบบบูลีนต้องมีการทดสอบอย่างน้อยสองครั้ง: การทดสอบหนึ่งมีผลเป็น "จริง" และอีกการทดสอบหนึ่งมีผลเป็น "เท็จ" ด้วยเหตุนี้ สำหรับโค้ดทุกบรรทัดที่เขียน โปรแกรมเมอร์มักต้องการโค้ดทดสอบ 3 ถึง 5 บรรทัด [11]เห็นได้ชัดว่าต้องใช้เวลาและการลงทุนอาจไม่คุ้มค่ากับความพยายาม มีปัญหาที่ไม่สามารถทดสอบได้ง่ายๆ เลย เช่น ปัญหาที่ไม่ได้กำหนดไว้หรือเกี่ยวข้องกับหลายเธรด นอกจากนี้ โค้ดสำหรับการทดสอบหน่วยมีแนวโน้มที่จะมีปัญหาพอๆ กับโค้ดที่กำลังทดสอบ เฟร็ด บรู กส์ ในThe Mythical Man-Month quotes: "อย่าไปทะเลด้วยโครโนมิเตอร์สองตัว จงใช้หนึ่งหรือสาม" (12)หมายความว่า ถ้าโครโนมิเตอร์ สองตัว ขัดแย้งกัน คุณจะรู้ได้อย่างไรว่าอันไหนถูกต้อง?

ความท้าทายอีกประการหนึ่งเกี่ยวกับการเขียนแบบทดสอบหน่วยคือความยากในการตั้งค่าการทดสอบที่เป็นจริงและมีประโยชน์ จำเป็นต้องสร้างเงื่อนไขเริ่มต้นที่เกี่ยวข้อง เพื่อให้ส่วนของแอปพลิเคชันที่กำลังทดสอบมีลักษณะเหมือนเป็นส่วนหนึ่งของระบบทั้งหมด หากเงื่อนไขเริ่มต้นเหล่านี้ไม่ได้ตั้งค่าไว้อย่างถูกต้อง การทดสอบจะไม่ใช้โค้ดในบริบทที่เป็นจริง ซึ่งจะทำให้ค่าและความแม่นยำของผลการทดสอบหน่วยลดลง [13]

เพื่อให้ได้ประโยชน์ตามที่ตั้งใจไว้จากการทดสอบหน่วย จำเป็นต้องมีวินัยที่เข้มงวดตลอดกระบวนการพัฒนาซอฟต์แวร์ จำเป็นอย่างยิ่งที่จะต้องเก็บบันทึกอย่างระมัดระวัง ไม่เพียงแต่การทดสอบที่ดำเนินการแล้ว แต่ยังรวมถึงการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับซอร์สโค้ดของซอฟต์แวร์นี้หรือหน่วยอื่นๆ ในซอฟต์แวร์ด้วย การใช้ ระบบ ควบคุมเวอร์ชันเป็นสิ่งสำคัญ หากเวอร์ชันที่ใหม่กว่าของหน่วยไม่ผ่านการทดสอบเฉพาะที่ผ่านการทดสอบก่อนหน้านี้ ซอฟต์แวร์ควบคุมเวอร์ชันสามารถระบุรายการการเปลี่ยนแปลงซอร์สโค้ด (ถ้ามี) ที่ใช้กับหน่วยตั้งแต่นั้นเป็นต้นมา [ ต้องการการอ้างอิง ]

นอกจากนี้ยังจำเป็นที่จะต้องใช้กระบวนการที่ยั่งยืนเพื่อให้มั่นใจว่ากรณีทดสอบที่ล้มเหลวจะได้รับการตรวจสอบอย่างสม่ำเสมอและแก้ไขทันที [14]หากกระบวนการดังกล่าวไม่ถูกนำไปใช้และฝังแน่นในเวิร์กโฟลว์ของทีม แอปพลิเคชันจะมีวิวัฒนาการไม่สอดคล้องกับชุดทดสอบยูนิต ซึ่งจะเพิ่มผลบวกที่ผิดพลาด และลดประสิทธิภาพของชุดทดสอบ

การทดสอบหน่วย ซอฟต์แวร์ระบบฝังตัวนำเสนอความท้าทายที่ไม่เหมือนใคร: เนื่องจากซอฟต์แวร์กำลังถูกพัฒนาบนแพลตฟอร์มที่แตกต่างจากแพลตฟอร์มที่จะรันในที่สุด คุณจึงไม่สามารถรันโปรแกรมทดสอบได้อย่างง่ายดายในสภาพแวดล้อมการปรับใช้จริง เช่นเดียวกับโปรแกรมเดสก์ท็อป [15]

การทดสอบหน่วยมักจะง่ายที่สุดเมื่อเมธอดมีพารามิเตอร์อินพุตและเอาต์พุตบางส่วน การสร้างการทดสอบหน่วยไม่ใช่เรื่องง่ายเมื่อหน้าที่หลักของวิธีการคือการโต้ตอบกับบางสิ่งภายนอกแอปพลิเคชัน ตัวอย่างเช่น วิธีการที่จะทำงานกับฐานข้อมูลอาจต้องมีการจำลองการโต้ตอบของฐานข้อมูล ซึ่งอาจจะไม่ครอบคลุมเท่าการโต้ตอบของฐานข้อมูลจริง [16] [ ต้องการแหล่งที่ดีกว่า ]

ตัวอย่าง

นี่คือชุดของกรณีทดสอบในJavaที่ระบุจำนวนขององค์ประกอบในการใช้งาน อย่างแรก ต้องมีอินเทอร์เฟซที่เรียกว่า Adder และคลาสการนำไปใช้ที่มีตัวสร้างอาร์กิวเมนต์เป็นศูนย์ที่เรียกว่า AdderImpl มันยังคงยืนยันว่าอินเทอร์เฟซของ Adder ควรมีวิธีการที่เรียกว่า add โดยมีพารามิเตอร์จำนวนเต็มสองตัวซึ่งจะคืนค่าจำนวนเต็มอื่น นอกจากนี้ยังระบุลักษณะการทำงานของวิธีนี้สำหรับค่าช่วงเล็กๆ ด้วยวิธีการทดสอบจำนวนหนึ่ง

นำเข้าคงที่ org.junit.Assert.assertEquals ;

นำเข้า org.junit.Test ;

 TestAdder คลาส สาธารณะ{ 

    
    @ ทดสอบโมฆะสาธารณะ testSumPositiveNumbersOneAndOne () { Adder adder = AdderImpl ใหม่(); assertEquals ( 2 , adder . เพิ่ม( 1 , 1 )); }  
            
          
    

    // มันบวกเลขบวก 1 กับ 2 ได้ไหม 
    @ ทดสอบโมฆะสาธารณะtestSumPositiveNumbersOneAndTwo 
    () { Adder adder = ใหม่AdderImpl (); assertEquals ( 3 , adder . เพิ่ม( 1 , 2 )); }   
            
          
    

    // มันบวกเลขบวก 2 กับ 2 ได้ไหม 
    @ ทดสอบโมฆะสาธารณะtestSumPositiveNumbersTwoAndTwo 
    () { Adder adder = ใหม่AdderImpl (); assertEquals ( 4 , adder . เพิ่ม( 2 , 2 )); }   
            
          
    

    // เป็นศูนย์เป็นกลาง? 
    @ ทดสอบโมฆะสาธารณะtestSumZeroNeutral 
    () { Adder adder = ใหม่AdderImpl (); assertEquals ( 0 , adder . เพิ่ม( 0 , 0 )); }   
            
          
    

    // มันบวกเลขลบ -1 กับ -2 ได้ไหม? 
    @ ทดสอบโมฆะสาธารณะtestSumNegativeNumbers 
    () { Adder adder = ใหม่AdderImpl (); assertEquals ( - 3 , adder . add ( - 1 , - 2 )); }   
            
          
    

    // เพิ่มบวกและลบได้หรือไม่? 
    @ ทดสอบโมฆะสาธารณะtestSumPositiveAndNegative 
    () { Adder adder = ใหม่AdderImpl (); assertEquals ( 0 , adder . เพิ่ม( - 1 , 1 )); }   
            
          
    

    // แล้วตัวเลขที่มากขึ้นล่ะ? 
    @ ทดสอบโมฆะสาธารณะtestSumLargeNumbers 
    () { Adder adder = AdderImpl ใหม่(); assertEquals ( 2222 , adder . add ( 1234 , 988 )); } }   
            
          
    

ในกรณีนี้ การทดสอบหน่วยที่เขียนขึ้นก่อนจะทำหน้าที่เป็นเอกสารการออกแบบที่ระบุรูปแบบและพฤติกรรมของโซลูชันที่ต้องการ แต่ไม่ใช่รายละเอียดการใช้งานซึ่งเหลือไว้สำหรับโปรแกรมเมอร์ ตามแนวทางปฏิบัติ "ทำสิ่งที่ง่ายที่สุดที่อาจเป็นไปได้" วิธีแก้ปัญหาที่ง่ายที่สุดที่จะทำให้ผ่านการทดสอบแสดงอยู่ด้านล่าง

อินเทอร์เฟซ Adder  { 
    int  เพิ่ม( int  a ,  int  b ); 
} 
class  AdderImpl  ใช้ Adder  { 
    public  int  add ( int  a ,  int  b )  { 
        return  a  +  b ; 
    } 
}

ตามข้อกำหนดที่ปฏิบัติการได้

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

การทดสอบหน่วยขาดความสามารถในการเข้าถึงข้อกำหนดเกี่ยวกับไดอะแกรม เช่น ไดอะแกรม UMLแต่อาจสร้างขึ้นจากการทดสอบหน่วยโดยใช้เครื่องมืออัตโนมัติ ภาษาสมัยใหม่ส่วนใหญ่มีเครื่องมือฟรี (มักใช้เป็นส่วนขยายของIDEs ) เครื่องมือฟรี เช่นเดียวกับเครื่องมือที่ใช้ เฟรมเวิร์ก xUnitจ้างงานระบบอื่นด้วยการแสดงภาพกราฟิกสำหรับการบริโภคของมนุษย์

แอปพลิเคชัน

การเขียนโปรแกรมขั้นสุดยอด

การทดสอบหน่วยเป็นรากฐานที่สำคัญของการเขียนโปรแกรม ขั้น สูง ซึ่งอาศัยเฟรมเวิร์กการทดสอบหน่วย แบบ อัตโนมัติ กรอบงานการทดสอบหน่วยอัตโนมัตินี้สามารถเป็นบุคคลที่สามได้ เช่นxUnitหรือสร้างขึ้นภายในกลุ่มการพัฒนา

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

รหัสส่วนใหญ่ในระบบเป็นหน่วยทดสอบ แต่ไม่จำเป็นต้องเป็นเส้นทางทั้งหมดผ่านรหัส Extreme Programming กำหนดให้ใช้กลยุทธ์ "ทดสอบทุกอย่างที่อาจทำลายได้" เหนือวิธี "ทดสอบทุกเส้นทางการดำเนินการ" แบบเดิม สิ่งนี้ทำให้นักพัฒนาพัฒนาการทดสอบน้อยกว่าวิธีดั้งเดิม แต่นี่ไม่ใช่ปัญหาจริง ๆ เป็นการปรับปรุงข้อเท็จจริง เนื่องจากวิธีการแบบคลาสสิกนั้นไม่ค่อยได้รับการปฏิบัติตามอย่างเป็นระบบเพียงพอสำหรับเส้นทางการดำเนินการทั้งหมดที่จะได้รับการทดสอบอย่างละเอียด [ ต้องการการอ้างอิง ] Extreme Programming ตระหนักดีว่าการทดสอบไม่ค่อยละเอียดถี่ถ้วน (เพราะมันมักจะแพงเกินไป และใช้เวลานานกว่าจะสามารถทำงานได้ในเชิงเศรษฐกิจ) และให้แนวทางในการมุ่งเน้นทรัพยากรที่มีจำกัดอย่างมีประสิทธิภาพ

สิ่งสำคัญที่สุดคือ รหัสทดสอบถือเป็นสิ่งประดิษฐ์ของโครงการระดับเฟิร์สคลาส โดยจะคงคุณภาพไว้เท่ากับรหัสการนำไปใช้งาน โดยลบการทำซ้ำทั้งหมดออก นักพัฒนาปล่อยรหัสการทดสอบหน่วยไปยังที่เก็บรหัสร่วมกับรหัสที่ทดสอบ การทดสอบหน่วยอย่างละเอียดของ Extreme Programming ให้ประโยชน์ดังที่กล่าวไว้ข้างต้น เช่น การพัฒนาโค้ดและการปรับโครงสร้างโค้ดที่ง่ายขึ้นและมั่นใจยิ่งขึ้น การรวมโค้ดที่ง่ายขึ้น เอกสารประกอบที่ถูกต้องแม่นยำ และการออกแบบโมดูลาร์เพิ่มเติม การทดสอบหน่วยเหล่านี้ยังทำงานอย่างต่อเนื่องในรูปแบบของ การทดสอบ การ ถดถอย

การทดสอบหน่วยยังมีความสำคัญต่อแนวคิดของการออกแบบฉุกเฉินอีกด้วย เนื่องจากการออกแบบที่เกิดขึ้นใหม่ขึ้นอยู่กับการปรับโครงสร้างใหม่ การทดสอบหน่วยจึงเป็นส่วนประกอบที่สำคัญ [17]

กรอบการทดสอบหน่วย

กรอบงานการทดสอบหน่วยมักเป็นผลิตภัณฑ์ของบุคคลที่สามซึ่งไม่ได้เผยแพร่เป็นส่วนหนึ่งของชุดคอมไพเลอร์ ช่วยให้ขั้นตอนการทดสอบหน่วยง่ายขึ้น โดยได้รับการพัฒนาสำหรับภาษาต่างๆมากมาย

โดยทั่วไป เป็นไปได้ที่จะทำการทดสอบหน่วยโดยไม่ได้รับการสนับสนุนจากเฟรมเวิร์กเฉพาะโดยการเขียนโค้ดไคลเอ็นต์ที่ฝึกหน่วยที่อยู่ภายใต้การทดสอบและใช้การยืนยันการจัดการข้อยกเว้นหรือกลไกโฟลว์การควบคุม อื่นๆ เพื่อส่งสัญญาณความล้มเหลว การทดสอบหน่วยโดยไม่มีกรอบการทำงานนั้นมีค่าเนื่องจากมีอุปสรรคในการนำการทดสอบหน่วยไปใช้ การมีการทดสอบหน่วยที่ไม่เพียงพอนั้นแทบจะไม่ดีไปกว่าการไม่มีเลย ในขณะที่เมื่อมีเฟรมเวิร์กแล้ว การเพิ่มการทดสอบหน่วยจะกลายเป็นเรื่องง่าย [18]ในบางกรอบงาน คุณสมบัติการทดสอบหน่วยขั้นสูงจำนวนมากขาดหายไปหรือต้องเข้ารหัสด้วยมือ

รองรับการทดสอบหน่วยระดับภาษา

ภาษาโปรแกรมบางภาษารองรับการทดสอบหน่วยโดยตรง ไวยากรณ์ของพวกเขาอนุญาตให้ประกาศโดยตรงของการทดสอบหน่วยโดยไม่ต้องนำเข้าไลบรารี (ไม่ว่าจะเป็นบุคคลที่สามหรือมาตรฐาน) นอกจากนี้ เงื่อนไขบูลีนของการทดสอบหน่วยสามารถแสดงในรูปแบบเดียวกับนิพจน์บูลีนที่ใช้ในโค้ดทดสอบที่ไม่ใช่หน่วย เช่น สิ่งที่ใช้สำหรับifและwhileคำสั่ง

ภาษาที่รองรับการทดสอบหน่วยในตัวประกอบด้วย:

บางภาษาที่ไม่มีการสนับสนุนการทดสอบหน่วยในตัวมีไลบรารี/เฟรมเวิร์กการทดสอบหน่วยที่ดีมาก ภาษาเหล่านั้นรวมถึง:

ดูเพิ่มเติม

อ้างอิง

  1. อรรถa b Kolawa อาดัม; ฮูซิงก้า, โดโรต้า (2007). การป้องกันข้อบกพร่องอัตโนมัติ: แนวทางปฏิบัติที่ดีที่สุดในการจัดการซอฟต์แวร์ Wiley-IEEE Computer Society Press. หน้า 75. ISBN 978-0-170-04212-0.
  2. ^ a b ฮามิลล์, พอล (2004). กรอบงานการทดสอบหน่วย: เครื่องมือสำหรับการพัฒนาซอฟต์แวร์คุณภาพสูง O'Reilly Media, Inc. ISBN 9780596552817.
  3. ^ เซียะ เต๋า . "สู่กรอบการทำงานสำหรับการทดสอบหน่วยส่วนต่างของโปรแกรมเชิงวัตถุ" (PDF ) สืบค้นเมื่อ23 กรกฎาคม 2555 .
  4. ฟาวเลอร์, มาร์ติน (2 มกราคม 2550) "เยาะเย้ยไม่ใช่สตับ" . สืบค้นเมื่อ1 เมษายน 2551 .
  5. ^ "เริ่มต้นใช้งาน xUnit.net (เดสก์ท็อป) "
  6. ^ "ทฤษฎี" . GitHub .
  7. ^ "การทดสอบแบบกำหนดพารามิเตอร์" . GitHub .
  8. โบห์ม แบร์รี่ ดับเบิลยู ; Papaccio, Philip N. (ตุลาคม 2531) "การทำความเข้าใจและควบคุมต้นทุนซอฟต์แวร์" (PDF ) ธุรกรรม IEEE เกี่ยวกับวิศวกรรมซอฟต์แวร์ 14 (10): 1462–1477. ดอย : 10.1109/32.6191 . สืบค้นเมื่อ13 พฤษภาคม 2559 .
  9. ^ "ทดสอบแต่เนิ่นๆ" . ไมโครซอฟต์.
  10. ^ "พิสูจน์ว่าใช้งานได้: การใช้ Unit Test Framework สำหรับการทดสอบซอฟต์แวร์และการตรวจสอบความถูกต้อง " ตราสารแห่งชาติ . 21 สิงหาคม 2017.
  11. แครมบลิตต์ บ๊อบ (20 กันยายน 2550) "Alberto Savoia ยกย่องการทดสอบซอฟต์แวร์" . สืบค้นเมื่อ29 พฤศจิกายน 2550 .
  12. บรูกส์, เฟรเดอริก เจ. (1995) [1975]. เดือนชายในตำนาน แอดดิสัน-เวสลีย์. หน้า 64 . ISBN 978-0-201-83595-3.
  13. โคลาวา, อดัม (1 กรกฎาคม 2552). "แนวปฏิบัติที่ดีที่สุดในการทดสอบหน่วย" . สืบค้นเมื่อ23 กรกฎาคม 2555 .
  14. ↑ daVeiga , Nada (6 กุมภาพันธ์ 2008) “เปลี่ยนรหัสโดยไม่ต้องกลัว : ใช้เครือข่ายความปลอดภัยการถดถอย” . สืบค้นเมื่อ8 กุมภาพันธ์ 2551 .
  15. คูชาร์สกี้, มาเร็ค (23 พฤศจิกายน 2554). "การทำให้การทดสอบหน่วยใช้งานได้จริงสำหรับการพัฒนาแบบเอ็มเบ็ดเด็ด" . สืบค้นเมื่อ20 กรกฎาคม 2020 .
  16. ^ http://wiki.c2.com/?UnitTestsAndDatabases
  17. ^ "การออกแบบฉุกเฉินที่คล่องตัว" . เปรียวเชอร์ปา 3 สิงหาคม 2553. เก็บข้อมูลจากต้นฉบับเมื่อ 22 มีนาคม 2555 . สืบค้นเมื่อ8 พฤษภาคม 2555 .
  18. ^ เทคโนโลยีการทดสอบเป้า (2549-2551) "เป้าหมายความคุ้มครองระดับกลาง" . สืบค้นเมื่อ24 มีนาคม 2552 .
  19. ^ "สเปกคริสตัล" . คริสตัล -lang.org สืบค้นเมื่อ18 กันยายน 2560 .
  20. ^ "การทดสอบหน่วย - ภาษาการเขียนโปรแกรม D " ง . ภาษาการเขียนโปรแกรม มูลนิธิภาษาดี. สืบค้นเมื่อ5 สิงหาคม 2560 .
  21. ^ "การทดสอบ - The Go Programming Language" . golang.org _ สืบค้นเมื่อ3 ธันวาคม 2556 .
  22. ^ เอกสาร Python (2016) "unittest -- กรอบการทดสอบหน่วย" . สืบค้นเมื่อ18 เมษายน 2559 .
  23. เวลส์, โนเอล; คัลเปปเปอร์, ไรอัน. "หน่วยแร็ค: การทดสอบหน่วย " พีแอลทีดีไซน์ อิงค์ สืบค้นเมื่อ26 กุมภาพันธ์ 2019 .
  24. เวลส์, โนเอล; คัลเปปเปอร์, ไรอัน. "ส่วนแพ็คเกจการทดสอบหน่วย RackUnit ของการแจกจ่ายหลักของแร็กเกต " พีแอลทีดีไซน์ อิงค์ สืบค้นเมื่อ26 กุมภาพันธ์ 2019 .
  25. ^ "Minitest (ทับทิม 2.0)" . Ruby-Doc.org.
  26. ^ ผู้พัฒนาโครงการสนิม (2554-2557) "คู่มือการทดสอบสนิม (สนิม 0.12.0 ก่อนคืน)" . สืบค้นเมื่อ12 สิงหาคม 2557 .
  27. เซียร์รา, สจวร์ต. "API สำหรับ clojure.test - Clojure v1.6 (เสถียร) " สืบค้นเมื่อ11 กุมภาพันธ์ 2558 .
  28. ^ "โครงงานรบกวน" . GitHub . สืบค้นเมื่อ28 มกราคม 2559 .

อ่านเพิ่มเติม

  • เฟเธอร์ส, ไมเคิล ซี. (2005). ทำงานอย่างมีประสิทธิภาพด้วยรหัสเดิม Upper Saddle River, NJ: ข้อมูลอ้างอิงทางเทคนิคระดับมืออาชีพของ Prentice Hall ISBN 978-0131177055.

ลิงค์ภายนอก