คำถามติดแท็ก assertions

18
รอบในซอฟต์แวร์ต้นไม้ครอบครัว
ล็อคแล้ว คำถามและคำตอบนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ ฉันเป็นผู้พัฒนาซอฟต์แวร์แผนภูมิต้นไม้บางตระกูล (เขียนด้วยภาษา C ++ และ Qt) ฉันไม่มีปัญหาจนกระทั่งลูกค้าคนใดคนหนึ่งส่งรายงานข้อผิดพลาดถึงฉัน ปัญหาคือลูกค้ามีลูกสองคนพร้อมกับลูกสาวของตนเองและทำให้เขาไม่สามารถใช้ซอฟต์แวร์ของฉันได้เนื่องจากข้อผิดพลาด ข้อผิดพลาดเหล่านั้นเป็นผลมาจากการยืนยันและค่าคงที่ต่างๆของฉันเกี่ยวกับกราฟครอบครัวที่กำลังประมวลผล (ตัวอย่างเช่นหลังจากเดินรอบโปรแกรมระบุว่า X ไม่สามารถเป็นทั้งพ่อและปู่ของ Y) ฉันจะแก้ไขข้อผิดพลาดเหล่านั้นโดยไม่ลบการยืนยันข้อมูลทั้งหมดได้อย่างไร



7
ฉันจะใช้ Assert ได้อย่างไรแถวเพื่อยืนยันประเภทของข้อยกเว้น
ฉันจะใช้Assert.Throwsเพื่อยืนยันประเภทของข้อยกเว้นและข้อความจริงได้อย่างไร บางสิ่งเช่นนี้ Assert.Throws<Exception>( ()=>user.MakeUserActive()).WithMessage("Actual exception message") วิธีที่ฉันกำลังทดสอบจะส่งข้อความที่มีประเภทเดียวกันหลายข้อความพร้อมกับข้อความที่แตกต่างกันและฉันต้องการวิธีทดสอบว่าข้อความที่ถูกต้องนั้นถูกส่งออกไปแล้วแต่บริบท

20
เมื่อใดที่ฉันควรใช้ Debug.Assert ()
ฉันเป็นวิศวกรซอฟต์แวร์มืออาชีพมาประมาณหนึ่งปีแล้วหลังจากสำเร็จการศึกษาระดับปริญญาตรี ฉันรู้เกี่ยวกับการยืนยันในขณะที่ใน C ++ และ C แต่ไม่รู้ว่าพวกเขามีอยู่ใน C # และ. NET เลยจนกระทั่งเมื่อไม่นานมานี้ รหัสการผลิตของเราไม่มีการยืนยันใด ๆ และคำถามของฉันคือสิ่งนี้ ... ฉันควรเริ่มใช้ Asserts ในรหัสการผลิตของเราหรือไม่ และถ้าเป็นเช่นนั้นการใช้งานที่เหมาะสมที่สุดเมื่อใด มันจะทำให้รู้สึกมากกว่าที่จะทำ Debug.Assert(val != null); หรือ if ( val == null ) throw new exception();

6
เปรียบเทียบ Array ใน JUnit assertions ในตัวแบบรัดกุม?
มีวิธีรัดกุมในตัวที่จะทำเท่ากับการยืนยันในสองอาร์เรย์เหมือนพิมพ์ใน JUnit? โดยค่าเริ่มต้น (อย่างน้อยใน JUnit 4) ดูเหมือนว่าจะทำการเปรียบเทียบกับวัตถุอาร์เรย์เอง EG ไม่ทำงาน: int[] expectedResult = new int[] { 116800, 116800 }; int[] result = new GraphixMask().sortedAreas(rectangles); assertEquals(expectedResult, result); แน่นอนฉันสามารถทำได้ด้วยตนเองด้วย: assertEquals(expectedResult.length, result.length); for (int i = 0; i < expectedResult.length; i++) assertEquals("mismatch at " + i, expectedResult[i], result[i]); .. แต่มีวิธีที่ดีกว่า
159 java  arrays  junit  assertions 


5
Eclipse: เปิดใช้งานการยืนยัน
ฉันใช้ Eclipse Galileo ฉันจะเปิดใช้งานการยืนยันใน Eclipse ได้อย่างไร ตามที่ไซต์อื่นแนะนำฉันได้ลองเพิ่มอาร์กิวเมนต์: -ea. ฉันได้ลองเปลี่ยนระดับการปฏิบัติตามข้อกำหนดของคอมไพเลอร์เป็น1.4. คำแนะนำเหล่านั้นไม่ได้ผล

8
Debug.Assert vs Exception Throwing
ฉันได้อ่านบทความมากมาย (และคำถามที่คล้ายกันอีกสองสามข้อที่โพสต์บน StackOverflow) เกี่ยวกับวิธีการและเวลาที่จะใช้การยืนยันและฉันเข้าใจดี แต่ถึงกระนั้นฉันก็ไม่เข้าใจว่าแรงจูงใจแบบไหนที่ควรผลักดันให้ฉันใช้Debug.Assertแทนที่จะทิ้งข้อยกเว้นธรรมดา ๆ สิ่งที่ฉันหมายถึงคือใน. NET การตอบสนองเริ่มต้นสำหรับการยืนยันที่ล้มเหลวคือการ "หยุดโลก" และแสดงกล่องข้อความให้กับผู้ใช้ แม้ว่าพฤติกรรมแบบนี้จะสามารถแก้ไขได้ แต่ฉันพบว่ามันน่ารำคาญและซ้ำซ้อนมากที่จะทำเช่นนั้นในขณะที่ฉันทำได้เพียงแค่โยนข้อยกเว้นที่เหมาะสมแทน ด้วยวิธีนี้ฉันสามารถเขียนข้อผิดพลาดลงในบันทึกของแอปพลิเคชันได้อย่างง่ายดายก่อนที่จะโยนข้อยกเว้นและนอกจากนี้แอปพลิเคชันของฉันไม่จำเป็นต้องหยุดทำงาน เหตุใดฉันจึงควรใช้Debug.Assertแทนข้อยกเว้นธรรมดา การวางคำยืนยันในที่ที่ไม่ควรเป็นเพียงแค่อาจทำให้เกิด "พฤติกรรมที่ไม่ต้องการ" ได้ทุกรูปแบบดังนั้นในมุมมองของฉันฉันไม่ได้ประโยชน์อะไรเลยจากการใช้การยืนยันแทนที่จะโยนข้อยกเว้น คุณเห็นด้วยกับฉันหรือว่าฉันพลาดอะไรที่นี่? หมายเหตุ:ฉันเข้าใจอย่างถ่องแท้ว่าความแตกต่างคือ "ในทางทฤษฎี" (Debug vs Release, รูปแบบการใช้งานและอื่น ๆ ) แต่อย่างที่ฉันเห็นฉันจะดีกว่าที่จะทิ้งข้อยกเว้นแทนการยืนยัน เนื่องจากหากพบข้อบกพร่องในรุ่นที่ใช้งานจริงฉันก็ยังคงต้องการให้ "การยืนยัน" ล้มเหลว (อย่างไรก็ตาม "ค่าใช้จ่าย" มีขนาดเล็กมาก) ดังนั้นฉันจะดีกว่าที่จะทิ้งข้อยกเว้นแทน แก้ไข:วิธีที่ฉันเห็นหากการยืนยันล้มเหลวนั่นหมายความว่าแอปพลิเคชันเข้าสู่สถานะที่เสียหายและไม่คาดคิด เหตุใดฉันจึงต้องการดำเนินการต่อไป? ไม่สำคัญว่าแอปพลิเคชันจะทำงานบนเวอร์ชันดีบักหรือเวอร์ชันรีลีส เช่นเดียวกันสำหรับทั้งสองอย่าง

6
ยืนยันกับ JUnit Assertions
วันนี้ฉันเห็นกรณีการทดสอบ JUnit ที่มีการยืนยัน java แทนการยืนยัน JUnit - มีข้อดีหรือข้อเสียที่สำคัญที่จะชอบมากกว่าอีกแบบหนึ่งหรือไม่?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.