JUnit 4 vs TestNG - อัปเดต 2013 - 2014 [ปิด]

JUnit 4 และ TestNG เคยเทียบเคียงกัน ข้อดีข้อเสียของกรอบการทดสอบทั้งสองคืออะไร?

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

เท่าที่ฉันบอกได้ด้วย JUnit4 คุณต้องสร้างคลาสทดสอบแยกต่างหากสำหรับชุดพารามิเตอร์แต่ละชุดที่คุณต้องการทดสอบด้วย (รันด้วย@RunWith(Parameterized.class)) ด้วย TestNG คุณสามารถมีผู้ให้บริการข้อมูลหลายรายในคลาสทดสอบเดียวดังนั้นคุณสามารถเก็บการทดสอบทั้งหมดของคุณสำหรับคลาสเดียวไว้ในคลาสทดสอบเดียวได้เช่นกัน

จนถึงตอนนี้เป็นสิ่งเดียวที่ฉันสามารถชี้ให้เห็นว่าเป็นประโยชน์ของ TestNG บน JUnit4

Intellij IDEA รองรับ TestNG และ JUnit ได้ทันที อย่างไรก็ตาม Eclipse สนับสนุนเฉพาะ JUnit นอกกรอบและต้องติดตั้งปลั๊กอิน TestNG เพื่อให้ใช้งานได้

อย่างไรก็ตามปัญหาที่น่ารำคาญกว่าที่ฉันพบกับ TestNG คือชั้นเรียนทดสอบของคุณจำเป็นต้องขยายออกไปPowerMockTestCaseหากคุณใช้ PowerMock เพื่อจำลองการอ้างอิงในการทดสอบของคุณ เห็นได้ชัดว่ามีหลายวิธีในการกำหนดค่า object-factory เฟรมเวิร์กการทดสอบของคุณจำเป็นต้องรู้เมื่อใช้ PowerMock ผ่านวิธีพิเศษหรือผ่านทางtestng.xmlคำจำกัดความของชุด แต่ดูเหมือนว่าจะเสียในขณะนี้ ฉันไม่ชอบให้ชั้นเรียนทดสอบขยายชั้นเรียนกรอบการทดสอบดูเหมือนว่าเป็นการแฮ็ก

หากคุณไม่ใช้ PowerMock นี่ไม่ใช่ปัญหาแน่นอน แต่โดยรวมแล้วฉันรู้สึกว่ารองรับ JUnit4 ได้ดีกว่า

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

• ใน@BeforeClassวิธีการtestng จะไม่คงที่และดำเนินการก่อนการทดสอบในคลาสนั้นจะรันแทนที่จะเป็นเมื่อโหลดคลาสทดสอบ (พฤติกรรม JUnit) ฉันเคยมีโครงการ JUnit ที่การทดสอบฐานข้อมูลทั้งหมด (ไม่กี่โหล) เริ่มต้นฐานข้อมูลตั้งแต่เริ่มต้นซึ่งเป็นพฤติกรรมที่ค่อนข้างงี่เง่า มีการถกเถียงกันมากมายเกี่ยวกับเรื่องนี้ในชุมชน JUnit ความสำคัญของมันคือทุกวิธีการทดสอบควรมีอุปกรณ์ทดสอบของตัวเองดังนั้นคุณไม่ควรมีเมธอดสไตล์ beforeAll ที่ไม่คงที่เพราะจะช่วยให้คุณสามารถตั้งค่าตัวแปรอินสแตนซ์ได้อย่างลับๆหนึ่งครั้งจากนั้นจึงใช้ในการทดสอบทั้งหมดของคุณ ใช้ได้ แต่น่ารำคาญมากสำหรับการทดสอบการรวมระบบ TestNG ให้ผู้ใช้มีทางเลือกที่นี่ Junit ไม่ได้ออกแบบซึ่งน่ารำคาญ

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

• คุณสามารถมาร์กอัปคลาสด้วย@Testใน testng ซึ่งหมายความว่าทุกวิธีสาธารณะคือการทดสอบ ใน Junit คุณต้องคัดลอก / วาง@Testทุกวิธี

สิ่งที่น่ารำคาญกับทั้งสองอย่างคือวิธีการรวมแฮมเครสต์กับ JUnit และวิธีที่ JUnit รวมเข้ากับการทดสอบ มีไหดัดแปลงใน maven ที่ไม่มีปัญหานี้

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

ฉันกำลังมองหาเหตุผลที่ดีในการเปลี่ยน TestNG เป็น JUnit และฉันพบสไลด์นี้โดย Tomek Kaczanowski ตอบคำถามนี้ได้เป็นอย่างดี Tomek เป็นผู้เขียนหนังสือPractical Unit Testingซึ่งนักพัฒนาและผู้ทดสอบดูเหมือนจะได้รับความเคารพอย่างมาก

หากคุณทำงานกับโปรเจ็กต์ Java / Scala และ Gradle เป็นเครื่องมือสร้างที่คุณเลือกโปรดจำไว้ว่าScalaTestเฟรมเวิร์กมีไว้JUnitRunnerเพื่อรันการทดสอบสกาลาของคุณเท่านั้น กล่าวอีกนัยหนึ่งคุณมีทางเลือก:

• การทดสอบ Java JUnit + การทดสอบ Scala ทำงานด้วย JUnitRunner => การรวม Gradle ที่ดีขึ้น
• การทดสอบ Java testNG + การทดสอบ Scala ทำงานด้วย Scala Runner => การรวม Gradle ที่ไม่ดีเนื่องจากนักวิ่งทดสอบ scala เป็นงานจำนวนมากจากมุมมองของ Gradle

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

โดยสังเขป..

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

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