ยืนยันกับ JUnit Assertions

85

วันนี้ฉันเห็นกรณีการทดสอบ JUnit ที่มีการยืนยัน java แทนการยืนยัน JUnit - มีข้อดีหรือข้อเสียที่สำคัญที่จะชอบมากกว่าอีกแบบหนึ่งหรือไม่?

— โรเบิร์ต
แหล่งที่มา

มีความแตกต่างอย่างแท้จริงระหว่างการยืนยัน JUnit และคีย์เวิร์ด 'assert' ของ Java นี่ไม่ใช่คำถามตามความคิดเห็น

— Thomas W

96

ใน JUnit4 ข้อยกเว้น (ข้อผิดพลาดจริง) ที่ส่งโดยการยืนยัน JUnit จะเหมือนกับข้อผิดพลาดที่เกิดจากassertคีย์เวิร์ดjava (AssertionError) ดังนั้นจึงเหมือนกับassertTrueและอื่น ๆ นอกเหนือจากการติดตามสแต็กที่คุณไม่สามารถบอกความแตกต่างได้

ตามที่กล่าวไว้การยืนยันต้องรันด้วยแฟล็กพิเศษใน JVM ทำให้การทดสอบหลายครั้งดูเหมือนจะผ่านเพียงเพราะมีคนลืมกำหนดค่าระบบด้วยแฟล็กนั้นเมื่อการทดสอบ JUnit ทำงาน - ไม่ดี

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

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

— ยี่ไฉ
แหล่งที่มา

26

ฉันชอบการยืนยัน JUnit เนื่องจากมี API ที่สมบูรณ์กว่าassertคำสั่งในตัวและที่สำคัญไม่จำเป็นต้องเปิดใช้งานอย่างชัดเจนซึ่งแตกต่างจากassertที่ต้องใช้-eaอาร์กิวเมนต์ JVM

— อดัมสกี
แหล่งที่มา

1

-eaถูกเปิดใช้งานเสมอในการจำเป็นที่จะต้องไม่มีmvn test -eaapi ที่ดีกว่าจับได้ดี บางครั้งฉันคิดว่า API ถูกใช้ในการทดสอบในทางที่ผิดเนื่องจากไม่ได้เป็นส่วนหนึ่งของแอปพลิเคชัน (a ใน api) ฉันชอบเรียกมันว่าวิธีที่สมบูรณ์กว่า

— Grim

20

เมื่อการทดสอบล้มเหลวคุณจะได้รับข้อมูลเพิ่มเติม

assertEquals(1, 2); ผลลัพธ์ใน java.lang.AssertionError: expected:<1> but was:<2>

เทียบกับ

assert(1 == 2); ผลลัพธ์ใน java.lang.AssertionError

คุณสามารถรับข้อมูลเพิ่มเติมได้หากคุณเพิ่มอาร์กิวเมนต์ข้อความลงใน assertEquals

— starmer
แหล่งที่มา

9

ลองassert 1==2: "1 is not 2";.

— Grim

@PeterRader ลองใช้คีย์เวิร์ดยืนยันเมื่อไม่ได้เปิดใช้งาน -ea หรือดีกว่านั้นให้ใช้การยืนยัน JUnit ซึ่งใช้ได้ผลเสมอ

— Thomas W

1

@ThomasW เมื่อไม่ได้เปิดใช้งาน -ea ไม่ใช่การทดสอบ JUnit asserations ไม่ได้ผลเสมอไป แต่จะใช้ได้ผลก็ต่อเมื่อคุณตัดสินใจที่จะใช้ JUnit อะไรคือกรอบงานและในกรณีของ maven a maven dependency การพึ่งพา maven ที่ต้องอยู่ในขอบเขตการทดสอบเท่านั้น เรามีสองด้านที่นี่: คุณชอบอะไร? ด้านที่ 1 : ใช้เฟรมเวิร์กเป็นตัวอ้างอิงในขอบเขตการทดสอบเท่านั้นที่ต้องดาวน์โหลดคราสนั้นให้คุณใช้ในคลาสที่ไม่ได้อยู่ในโฟลเดอร์ src / main แต่จะไม่คอมไพล์ที่นั่นเนื่องจาก maven มี junit เฉพาะในการทดสอบ - ขอบเขตหรือด้านที่ 2 : ใช้สิ่งที่สร้างขึ้น

— Grim

1

@PeterRader คำถามนี้เกี่ยวกับกรณีทดสอบ JUnit ในบริบทนั้นควรใช้ JUnit หรือคลาสการยืนยันที่คล้ายกันเนื่องจากจะเปิดใช้งานเสมอ ฉันเคยถูกจับโดยคำหลัก 'assert' ของ Java ที่ไม่ได้เปิดใช้งานในอดีตและไม่เชื่อว่าการยืนยันที่ไม่น่าเชื่อถือมีส่วนในรหัสทดสอบ

— Thomas W

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

— Thomas W

8

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

— บรูโนดี. โรดริเกซ
แหล่งที่มา

0

ฉันจะบอกว่าถ้าคุณใช้ JUnit คุณควรใช้การยืนยัน JUnit assertTrue()โดยพื้นฐานแล้วจะเหมือนกับassertมิฉะนั้นทำไมถึงใช้ JUnit?

— ชีส
แหล่งที่มา

4

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

— Yishai

1

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

— CheesePls

1

@CheesePls "ข้อความยืนยันแบบเก่าปกติ" ในความเป็นจริงล่าสุดมากกว่าที่ JUnit ยืนยัน

— dolmen

0

สิ่งนี้อาจใช้ไม่ได้หากคุณใช้เฉพาะสิ่งที่มันเงาและใหม่ แต่การยืนยันไม่ได้ถูกนำมาใช้ใน Java จนถึง 1.4SE ดังนั้นหากคุณต้องทำงานในสภาพแวดล้อมที่มีเทคโนโลยีรุ่นเก่าคุณอาจพึ่งพา JUnit ด้วยเหตุผลด้านความเข้ากันได้

— แดนโคตส์
แหล่งที่มา