คุณทดสอบโค้ดหน่วยโดยใช้โครงสร้างกราฟได้อย่างไร

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

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

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

ป.ล. -ถ้ามันสำคัญขอบทั้งหมดในกราฟของฉันจะมีป้ายกำกับว่า "ต้องมี" xor "ไม่สามารถมี" และไม่มีวัฏจักรเล็กน้อยและมีเพียงขอบเดียวระหว่างสองโหนด

PPS-คำสั่งปัญหาเพิ่มเติมนี้เดิมถูกโพสต์โดยผู้เขียนคำถามในความคิดเห็นด้านล่าง:

For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all must either use only edges labelled 'conflict' or 'requires'.

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

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

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

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

1. การสร้างแบบทดสอบสุ่ม

เขียนอัลกอริธึมที่สร้างกราฟให้สร้างกราฟสุ่มสองสามร้อย (หรือมากกว่า) แล้วโยนแต่ละอันที่อัลกอริธึมของคุณ

เก็บเมล็ดแบบสุ่มของกราฟที่ทำให้เกิดความล้มเหลวที่น่าสนใจและเพิ่มการทดสอบหน่วย

2. รหัสยากส่วนยาก

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

3. สร้างรายการครบถ้วนสมบูรณ์

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

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

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

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

foreach nodes as node
    foreach nodes as tmp
        tmp.status = unmarked

    tovisit = []
    tovisit.push(node)
    node.status = required

    while |tovisit| > 0 do
        next = tovisit.pop()
        foreach next.requires as requirement
            if requirement.status = unmarked
                tovisit.push(requirement)
                requirement.status = required
            else if requirement.status = blacklisted
                return false
        foreach next.collides as collision
            if collision.status = unmarked
                requirement.status = blacklisted
            else if requirement.status = required
                return false
return true

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

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

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

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

อย่างที่คุณเห็นไม่มีความจำเป็นที่จะต้องคิดค้นล้อใหม่อีกเลย

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

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

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

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

ในระยะสั้น TDD

• เขียนแบบทดสอบ
• ดูว่ามันล้มเหลว
• แก้ไขรหัส
• ตรวจสอบให้แน่ใจว่าการทดสอบทั้งหมดผ่าน
• ปรับปรุงโครงสร้าง

และทำซ้ำวงจร

ในสถานการณ์เฉพาะนี้

1. การทดสอบครั้งแรกจะเป็นกราฟโหนดเดี่ยวที่อัลกอริทึมไม่ควรกลับวงจรใด ๆ
2. อันที่สองจะเป็นกราฟสามโหนดโดยไม่มีวัฏจักรที่อัลกอริทึมไม่ควรส่งคืนรอบใด ๆ
3. อันถัดไปคือการใช้กราฟสามโหนดกับวงรอบที่อัลกอริทึมไม่ควรส่งคืนรอบใด ๆ
4. ตอนนี้คุณสามารถทดสอบกับวงจรที่ซับซ้อนขึ้นอีกเล็กน้อยขึ้นอยู่กับความเป็นไปได้

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

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

ความเข้าใจของฉันเกี่ยวกับปัญหาตามที่ระบุไว้เดิมและปรับปรุงแล้วโดยความคิดเห็นภายใต้คำตอบของ Macke รวมถึงต่อไปนี้: 1) ทั้งสองประเภทขอบ (อ้างอิงและความขัดแย้ง) ถูกนำ; 2) ถ้าสองโหนดเชื่อมต่อกันด้วยหนึ่งขอบพวกเขาจะต้องไม่เชื่อมต่อกันแม้ว่ามันจะเป็นประเภทอื่นหรือย้อนกลับ; 3) หากเส้นทางระหว่างสองโหนดสามารถสร้างขึ้นได้โดยการผสมขอบประเภทต่าง ๆ นั่นก็เป็นข้อผิดพลาดแทนที่จะเป็นกรณีที่ถูกเพิกเฉย 4) หากมีเส้นทางระหว่างสองโหนดที่ใช้ขอบของประเภทหนึ่งแสดงว่าอาจไม่มีเส้นทางอื่นระหว่างพวกเขาโดยใช้ขอบประเภทอื่น 5) ไม่อนุญาตให้ใช้รอบแบบขอบเดี่ยวหรือชนิดขอบแบบผสม (จากการเดาแอปพลิเคชันฉันไม่แน่ใจว่ารอบข้อขัดแย้งเท่านั้นเป็นข้อผิดพลาด แต่เงื่อนไขนี้สามารถลบได้หากไม่ได้)

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

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

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

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

คุณต้องพิจารณาเส้นทางจากโหนดแรกแม้ว่ากราฟจะถูกตัดการเชื่อมต่อเนื่องจากเส้นทางจากโหนดอื่นจะปรากฏเป็นเส้นทางจากโหนดแรกในบางกรณี

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

หากคุณจำเส้นทางที่พบในการตรวจสอบกราฟของโหนด N-1 คุณสามารถใช้พวกเขาเป็นจุดเริ่มต้นสำหรับการสร้างและประเมินกราฟของโหนด N

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

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

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