ข้อมูลแบบสุ่มในการทดสอบหน่วย

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

ฉันได้ให้เหตุผลหลายอย่างกับเขาในเรื่องนี้เหตุผลหลักคือ:

• ค่าสุ่มหมายความว่าการทดสอบไม่สามารถทำซ้ำได้อย่างแท้จริง (ซึ่งหมายความว่าหากการทดสอบสามารถล้มเหลวแบบสุ่มได้ก็สามารถทำได้บนเซิร์ฟเวอร์การสร้างและการทำลายโครงสร้าง)
• ถ้ามันเป็นค่าสุ่มและการทดสอบล้มเหลวเราจำเป็นต้อง a) แก้ไขวัตถุและ b) บังคับให้เราทดสอบค่านั้นทุกครั้งเพื่อให้เรารู้ว่ามันใช้งานได้ แต่เนื่องจากเป็นการสุ่มเราจึงไม่ทราบว่าค่านั้นคืออะไร

เพื่อนร่วมงานอีกคนที่เพิ่ม:

• หากฉันกำลังทดสอบข้อยกเว้นค่าสุ่มจะไม่ทำให้แน่ใจว่าการทดสอบสิ้นสุดลงในสถานะที่คาดหวัง
• ข้อมูลแบบสุ่มใช้สำหรับการชะล้างระบบและทดสอบโหลดไม่ใช่สำหรับการทดสอบหน่วย

ใครสามารถเพิ่มเหตุผลเพิ่มเติมที่ฉันสามารถให้เขาเพื่อให้เขาหยุดทำสิ่งนี้ได้หรือไม่?

(หรืออีกวิธีหนึ่งนี่เป็นวิธีที่ยอมรับได้ในการเขียนการทดสอบหน่วยและฉันและเพื่อนร่วมงานคนอื่น ๆ ของฉันผิดหรือเปล่า?)

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

ข้อมูลจำเพาะของโปรแกรม (หรือหน่วย) เป็นข้อสมมติฐานว่ามีบางโปรแกรมที่ตรงกับมัน โปรแกรมนั้นเป็นหลักฐานของสมมติฐานนั้น การทดสอบหน่วยใดที่ควรจะเป็นความพยายามที่จะให้หลักฐานตอบโต้เพื่อปฏิเสธว่าโปรแกรมทำงานตามข้อมูลจำเพาะ

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

ฉันไม่รู้ว่าคุณใช้ภาษาอะไร แต่ดูที่นี่:

Java http://functionaljava.org/

Scala (หรือ Java) http://github.com/rickynils/scalacheck

Haskell http://www.cs.chalmers.se/~rjmh/QuickCheck/

.NET: http://blogs.msdn.com/dsyme/archive/2008/08/09/fscheck-0-2.aspx

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

การทดสอบมีความสุข!

ชนิดของการทดสอบนี้เรียกว่าการทดสอบลิง เมื่อทำถูกต้องมันสามารถกำจัดแมลงออกจากมุมมืด

เพื่อจัดการกับข้อกังวลของคุณเกี่ยวกับความสามารถในการทำซ้ำ: วิธีการที่ถูกต้องในการทำเช่นนี้คือการบันทึกรายการทดสอบที่ล้มเหลวสร้างหน่วยทดสอบซึ่งโพรบสำหรับครอบครัวทั้งหมดของบั๊กเฉพาะ และรวมอยู่ในหน่วยทดสอบหนึ่งอินพุตเฉพาะ (จากข้อมูลสุ่ม) ซึ่งทำให้เกิดความล้มเหลวในเบื้องต้น

มีบ้านครึ่งทางที่นี่มีการใช้งานบางอย่างซึ่งก็คือการหว่าน PRNG ของคุณด้วยค่าคงที่ ที่ช่วยให้คุณสร้างข้อมูล 'สุ่ม' ซึ่งสามารถทำซ้ำได้

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

ในหนังสือBeautiful Codeมีบทหนึ่งชื่อ "Beautiful Tests" ซึ่งเขาได้ทดสอบกลยุทธ์สำหรับอัลกอริทึมBinary Search ย่อหน้าหนึ่งเรียกว่า "การกระทำแบบสุ่มของการทดสอบ" ซึ่งเขาสร้างอาร์เรย์แบบสุ่มเพื่อทดสอบอัลกอริทึมอย่างละเอียด คุณสามารถอ่านหนังสือออนไลน์นี้ได้ที่ Google หนังสือหน้า 95แต่เป็นหนังสือที่มีค่ามาก

โดยพื้นฐานแล้วนี่แสดงให้เห็นว่าการสร้างข้อมูลแบบสุ่มสำหรับการทดสอบเป็นตัวเลือกที่ทำงานได้

ฉันชอบการทดสอบแบบสุ่มและฉันก็เขียนมัน อย่างไรก็ตามไม่ว่าพวกเขาจะมีความเหมาะสมในสภาพแวดล้อมการสร้างที่เฉพาะเจาะจงและห้องทดสอบใดที่พวกเขาควรจะรวมอยู่ในคำถามที่เหมาะสมยิ่งขึ้น

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

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

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

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

ในพื้นที่เช่นเมื่อเปลี่ยนคลาสที่เกี่ยวข้องคุณมีอิสระในการรันเพื่อทำซ้ำได้มากขึ้นหรือใช้กับเมล็ดอื่น หากการทดสอบแบบสุ่มกลายเป็นที่นิยมมากขึ้นคุณอาจจินตนาการถึงชุดการทดสอบเฉพาะที่ทราบกันว่าเป็นแบบสุ่มซึ่งสามารถทำงานกับเมล็ดที่แตกต่างกันได้ ในฐานะที่เป็นระบบ CI ที่กำหนดขึ้นเอง (กล่าวคือการรันไม่ได้เชื่อมโยงกับ 1: 1 กับการเปลี่ยนแปลงโค้ดดังนั้นคุณจึงไม่ต้องใช้นิ้วชี้ไปที่การเปลี่ยนแปลงเฉพาะเมื่อสิ่งต่าง ๆ ล้มเหลว)

มีหลายสิ่งที่ต้องบอกว่าสำหรับการทดสอบแบบสุ่มโดยเฉพาะอย่างยิ่งข้อเขียนที่เขียนได้ดีดังนั้นอย่าเร็วเกินไปที่จะยกเลิก!

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

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

ฉันพูดเกินจริง แต่ฉันชอบที่จะแทรกข้อมูลแบบสุ่มลงในการทดสอบของฉันเป็นสัญญาณว่า "ค่าของตัวแปรนี้ไม่ควรส่งผลกระทบต่อผลการทดสอบนี้"

ฉันจะบอกว่าถ้าคุณใช้ตัวแปรสุ่มแล้วแยกการทดสอบของคุณตามตัวแปรนั้นนั่นคือกลิ่น

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

• ถ้ามันเป็นค่าสุ่มและการทดสอบล้มเหลวเราจำเป็นต้อง a) แก้ไขวัตถุและ b) บังคับให้เราทดสอบค่านั้นทุกครั้งเพื่อให้เรารู้ว่ามันใช้งานได้ แต่เนื่องจากเป็นการสุ่มเราจึงไม่ทราบว่าค่านั้นคืออะไร

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

เพื่อนร่วมงานของคุณกำลังทำการทดสอบฟัซซี่ถึงแม้ว่าเขาจะไม่รู้เรื่องก็ตาม พวกเขามีค่าโดยเฉพาะอย่างยิ่งในระบบเซิร์ฟเวอร์

คุณสามารถสร้างข้อมูลสุ่มได้หนึ่งครั้ง (ฉันหมายถึงหนึ่งครั้งไม่ใช่หนึ่งครั้งต่อการทดสอบการทำงาน) จากนั้นใช้ในการทดสอบทั้งหมดหลังจากนั้นหรือไม่

ฉันสามารถเห็นค่าในการสร้างข้อมูลแบบสุ่มเพื่อทดสอบกรณีที่คุณไม่ได้คิด แต่คุณถูกต้องการทดสอบหน่วยที่สามารถสุ่มผ่านหรือล้มเหลวนั้นเป็นสิ่งที่ไม่ดี

คุณควรถามตัวเองว่าเป้าหมายของการทดสอบของคุณคืออะไร
การทดสอบหน่วยเกี่ยวกับการตรวจสอบตรรกะการไหลของรหัสและการโต้ตอบวัตถุ การใช้ค่าสุ่มพยายามที่จะบรรลุเป้าหมายที่แตกต่างกันซึ่งจะช่วยลดการทดสอบโฟกัสและความเรียบง่าย เป็นที่ยอมรับได้เนื่องจากเหตุผลด้านความสามารถในการอ่าน (การสร้าง UUID, รหัส, กุญแจ ฯลฯ )
โดยเฉพาะสำหรับการทดสอบหน่วยฉันไม่สามารถจำได้แม้เมื่อวิธีนี้ประสบความสำเร็จในการค้นหาปัญหา แต่ฉันได้เห็นปัญหาหลายระดับ (ในการทดสอบ) พยายามฉลาดด้วยค่าสุ่มและส่วนใหญ่กับวันที่สุ่ม
ทดสอบ Fuzz เป็นวิธีการที่ถูกต้องสำหรับการทดสอบการรวมและการทดสอบแบบ end-to-end

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

แนวคิดของข้อมูล "โดยพลการ" นั้นก็มีประโยชน์มากเช่นกันในการบ่งบอกบางสิ่งที่ไม่สำคัญ เรามีการทดสอบการยอมรับที่คำนึงถึงว่ามีข้อมูลเสียงมากมายที่ไม่มีความเกี่ยวข้องกับการทดสอบในมือ

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

วันนี้เราเพิ่งเจอกัน ฉันต้องการสุ่มหลอก (ดังนั้นมันจะดูเหมือนข้อมูลเสียงที่ถูกบีบอัดในแง่ของขนาด) ฉัน TODO'd ว่าผมยังต้องการที่กำหนด Rand () มีความแตกต่างใน OSX มากกว่าบน Linux และถ้าฉันไม่มีการเพาะซ้ำมันก็สามารถเปลี่ยนแปลงได้ตลอดเวลา ดังนั้นเราจึงเปลี่ยนให้เป็นแบบกำหนดได้ แต่ยังคงสุ่ม - psuedo: การทดสอบสามารถทำซ้ำได้มากเท่ากับการใช้ข้อมูลกระป๋อง (แต่เขียนได้สะดวกกว่า)

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

นั่นยังคงมีคุณสมบัติเป็นแบบสุ่ม? มาคุยกันเรื่องเบียร์กันดีกว่า :-)

ฉันสามารถจินตนาการถึงสามแนวทางในการแก้ไขปัญหาข้อมูลการทดสอบ:

• ทดสอบกับข้อมูลคงที่
• ทดสอบด้วยข้อมูลสุ่ม
• สร้างข้อมูลสุ่มครั้งเดียวจากนั้นใช้เป็นข้อมูลคงที่ของคุณ

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

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

ผู้ชายของคุณจะทำการทดสอบอีกครั้งได้อย่างไรเมื่อไม่สามารถตรวจสอบได้ว่าเขาแก้ไขแล้วหรือไม่? คือเขาสูญเสียการทำซ้ำของการทดสอบ

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

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