ทำไมต้องใช้ JUnit ในการทดสอบ


131

บางทีคำถามของฉันอาจจะเป็นมือใหม่ แต่ฉันก็ไม่เข้าใจสถานการณ์ที่จะใช้ เหรอ?

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

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

ทำไมไม่เขียนคลาสและทดสอบพร้อมกันSystem.outแต่ไม่สร้างคลาสแบบทดสอบ

ปล. ฉันไม่เคยทำงานในโครงการขนาดใหญ่ที่ฉันเพิ่งเรียนรู้

แล้วจุดประสงค์คืออะไร?



7
คุณทราบดีว่าทุกครั้งที่คุณเปลี่ยนแปลงสิ่งใด ๆ ในโปรแกรมของคุณงานก่อนหน้าทั้งหมดของการตรวจสอบผลลัพธ์ด้วยตนเองจะไม่ถูกต้องและคุณต้องทำซ้ำตั้งแต่เริ่มต้น?
Thorbjørn Ravn Andersen

ไม่ใช่แค่ "การทดสอบ" แต่ "การทดสอบอย่างชาญฉลาด" ก็มีความสำคัญมากเช่นกัน นี่คือตัวอย่างที่ดีของมัน: wp.me/prMeE-11
akcasoy

คำตอบ:


140

นั่นไม่ใช่การทดสอบนั่นคือ "การดูเอาต์พุตด้วยตนเอง" (รู้จักกันในชื่อ Biz ว่า LMAO) อย่างเป็นทางการเรียกว่า "การค้นหาผลลัพธ์ที่ผิดปกติด้วยตนเอง" (LMFAO) (ดูหมายเหตุด้านล่าง)

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

ตอนนี้ปรับขนาดได้ถึง 50k, 250k, 1m LOC หรือมากกว่าและ LMFAO ทุกครั้งที่คุณทำการเปลี่ยนแปลงรหัส ไม่เพียง แต่จะไม่เป็นที่พอใจ แต่ยังเป็นไปไม่ได้: คุณได้ปรับขนาดการรวมกันของอินพุตเอาต์พุตแฟล็กเงื่อนไขและเป็นการยากที่จะใช้ทุกสาขาที่เป็นไปได้

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

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

ไม่ว่าเราจะคิดว่าเราเก่งแค่ไหน แต่มนุษย์ก็ไม่ได้เป็นกรอบการทดสอบหน่วยหรือเซิร์ฟเวอร์ CI ที่ดี


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


3
-1 สำหรับประโยคแรกซึ่งไม่เป็นความจริงอย่างสิ้นเชิง
Michael Borgwardt

50

เราเขียนการทดสอบเพื่อตรวจสอบความถูกต้องของพฤติกรรมของโปรแกรม

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

คุณสามารถโต้แย้งได้

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

ก่อนอื่นขอแนะนำให้คุณสนใจว่ารหัสทำงานถูกต้องหรือไม่ นั่นเป็นสิ่งที่ดี คุณมาก่อนโค้ง! น่าเศร้าที่มีปัญหานี้เป็นแนวทาง

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

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

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

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

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

นั่นหมายความว่าดวงตาคู่ใหม่มีสองเส้นที่ถ่ายทอดสดและเอกสารที่ถูกต้องเกี่ยวกับรหัสที่เป็นปัญหา

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

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

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

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

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

การทดสอบที่มีการทำงานโดยอัตโนมัติรักษาความสมบูรณ์ของพฤติกรรมของรหัสและช่วยในการป้องกันการเปลี่ยนแปลงในอนาคตที่จะฐานรหัสจากการทำลายรหัส

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

มีข้อแม้ในการทดสอบการพัฒนาแบบขับเคลื่อนและนั่นคือคุณต้องเขียนโค้ดด้วยตาเพื่อให้สามารถทดสอบได้ สิ่งนี้เกี่ยวข้องกับการเข้ารหัสอินเทอร์เฟซและการใช้เทคนิคต่างๆเช่น Dependency Injection เพื่อสร้างอินสแตนซ์อ็อบเจ็กต์ที่ทำงานร่วมกัน ตรวจสอบผลงานของKent Beckที่อธิบาย TDD ได้เป็นอย่างดี ค้นหาการเข้ารหัสอินเทอร์เฟซและศึกษา


13

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

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

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

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

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


9

ฉันเพิ่ม System.out อื่น ๆ ไม่สามารถทำได้:

  • ทำให้แต่ละกรณีการทดสอบเป็นอิสระ (เป็นสิ่งสำคัญ)

    JUnit สามารถทำได้: ทุกครั้งที่มีการสร้างและ@Beforeเรียกอินสแตนซ์กรณีทดสอบใหม่

  • แยกรหัสการทดสอบจากแหล่งที่มา

    JUnit ก็ทำได้

  • บูรณาการกับ CI

    JUnit ทำได้ด้วย Ant และ Maven

  • จัดเรียงและรวมกรณีทดสอบได้อย่างง่ายดาย

    JUnit สามารถทำ@Ignoreและทดสอบชุดได้

  • ตรวจสอบผลได้ง่าย

    JUnit เสนอวิธีการยืนยันมากมาย ( assertEquals, assertSame... )

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

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


9

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

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

นอกจากนี้ยังมีคุณสมบัติขั้นสูงเพิ่มเติมใน JUnit เช่น like

ยืนยันคำสั่ง

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

บางส่วนของวิธีการเหล่านี้คือ

  1. fail([message])- ให้การทดสอบล้มเหลว อาจใช้เพื่อตรวจสอบว่าโค้ดไม่ถึงบางส่วน หรือมีการทดสอบที่ล้มเหลวก่อนที่จะใช้รหัสทดสอบ
  2. assertTrue(true)/ assertTrue(false)- จะเป็นจริง / เท็จเสมอ สามารถใช้เพื่อกำหนดผลการทดสอบล่วงหน้าหากยังไม่ได้ดำเนินการทดสอบ
  3. assertTrue([message,] condition)- ตรวจสอบว่าบูลีนconditionเป็นจริง
  4. assertEquals([message,] expected, actual)- ทดสอบว่าค่าสองค่าเท่ากันหรือไม่ (ตามequalsวิธีการหากนำไปใช้หรือใช้==การเปรียบเทียบอ้างอิง) หมายเหตุ: สำหรับอาร์เรย์เป็นการอ้างอิงที่ถูกตรวจสอบไม่ใช่เนื้อหาให้ใช้assertArrayEquals([message,] expected, actual)สำหรับสิ่งนั้น
  5. assertEquals([message,] expected, actual, delta)- ทดสอบว่าค่าสองค่าลอยหรือค่าคู่อยู่ในระยะห่างจากกันหรือไม่โดยควบคุมโดยdeltaค่านั้น
  6. assertNull([message,] object) - ตรวจสอบว่าวัตถุนั้นเป็นโมฆะ

และอื่น ๆ ดู Javadoc เต็มรูปแบบสำหรับตัวอย่างทั้งหมดที่นี่

ห้องสวีท

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

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ MyClassTest.class, MySecondClassTest.class })
public class AllTests { } 

6

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


4

JUnit เป็นกรอบการทดสอบหน่วยสำหรับภาษาการเขียนโปรแกรม Java เป็นสิ่งสำคัญในการพัฒนาที่ขับเคลื่อนด้วยการทดสอบและเป็นหนึ่งในตระกูลของกรอบการทดสอบหน่วยที่เรียกรวมกันว่า xUnit

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

คุณสมบัติ JUnit เป็นเฟรมเวิร์กโอเพ่นซอร์สที่ใช้สำหรับการเขียนและการทดสอบ

ให้คำอธิบายประกอบเพื่อระบุวิธีการทดสอบ

ให้การยืนยันสำหรับการทดสอบผลลัพธ์ที่คาดหวัง

จัดเตรียมนักวิ่งทดสอบสำหรับการทดสอบการวิ่ง

การทดสอบ JUnit ช่วยให้คุณเขียนโค้ดได้เร็วขึ้นซึ่งจะเพิ่มคุณภาพ

JUnit เรียบง่ายอย่างหรูหรา มีความซับซ้อนน้อยกว่าและใช้เวลาน้อยลง

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

การทดสอบ JUnit สามารถจัดเป็นชุดทดสอบที่มีกรณีทดสอบและแม้แต่ชุดทดสอบอื่น ๆ

Junit แสดงความคืบหน้าของการทดสอบในแถบที่เป็นสีเขียวหากการทดสอบดำเนินไปด้วยดีและจะเปลี่ยนเป็นสีแดงเมื่อการทดสอบล้มเหลว


2

ฉันมีมุมมองที่แตกต่างกันเล็กน้อยว่าทำไมต้องใช้ JUnit

คุณสามารถเขียนกรณีทดสอบทั้งหมดได้ด้วยตัวเอง แต่ก็ยุ่งยาก นี่คือปัญหา:

  1. แทนที่จะSystem.outเพิ่มif(value1.equals(value2))และส่งกลับ 0 หรือ -1 หรือข้อความแสดงข้อผิดพลาด ในกรณีนี้เราจำเป็นต้องมีคลาสทดสอบ "หลัก" ซึ่งเรียกใช้วิธีการเหล่านี้ทั้งหมดและตรวจสอบผลลัพธ์และดูแลว่ากรณีทดสอบใดล้มเหลวและกรณีใดที่ผ่าน

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

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

นี่คือสิ่งที่ JUnit กำลังทำ:

  1. มีassertXXX()วิธีการที่มีประโยชน์สำหรับการพิมพ์ข้อความแสดงข้อผิดพลาดที่เป็นประโยชน์จากเงื่อนไขและการสื่อสารผลลัพธ์ไปยังคลาส "หลัก"

  2. คลาส "main" เรียกว่า runner ซึ่งจัดทำโดย JUnit ดังนั้นเราจึงไม่ต้องเขียนใด ๆ และตรวจจับวิธีการทดสอบโดยอัตโนมัติโดยการสะท้อนกลับ หากคุณเพิ่มการทดสอบใหม่พร้อม@Testคำอธิบายประกอบจะตรวจพบโดยอัตโนมัติ

  3. JUnit มีการรวม eclipse และการรวม maven / gradle ด้วยดังนั้นจึงง่ายต่อการเรียกใช้การทดสอบและคุณจะไม่ต้องเขียนการกำหนดค่าการรันแบบกำหนดเอง

ฉันไม่ใช่ผู้เชี่ยวชาญใน JUnit ดังนั้นนั่นคือสิ่งที่ฉันเข้าใจในตอนนี้และจะเพิ่มมากขึ้นในอนาคต


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

1

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

Junit คืออะไร?

Junit เป็นกรอบการทดสอบที่ใช้กันอย่างแพร่หลายพร้อมกับ Java Programming Language คุณสามารถใช้กรอบการทำงานอัตโนมัตินี้สำหรับทั้งการทดสอบหน่วยและการทดสอบ UI ช่วยให้เรากำหนดขั้นตอนการเรียกใช้โค้ดของเราด้วยคำอธิบายประกอบที่แตกต่างกัน Junit สร้างขึ้นจากแนวคิดของ "การทดสอบครั้งแรกและการเข้ารหัส" ซึ่งช่วยให้เราสามารถเพิ่มประสิทธิผลของกรณีทดสอบและความเสถียรของโค้ดได้

คุณสมบัติที่สำคัญของการทดสอบ Junit -

  1. เป็นกรอบการทดสอบโอเพ่นซอร์สที่ช่วยให้ผู้ใช้สามารถเขียนและเรียกใช้กรณีทดสอบได้อย่างมีประสิทธิภาพ
  2. ให้คำอธิบายประกอบประเภทต่างๆเพื่อระบุวิธีการทดสอบ
  3. ให้การยืนยันประเภทต่างๆเพื่อตรวจสอบผลลัพธ์ของการดำเนินการกรณีทดสอบ
  4. นอกจากนี้ยังให้นักวิ่งทดสอบสำหรับการทดสอบการวิ่งอย่างมีประสิทธิภาพ
  5. มันง่ายมากและประหยัดเวลา
  6. มีวิธีจัดระเบียบกรณีทดสอบของคุณในรูปแบบของชุดทดสอบ
  7. ให้ผลกรณีทดสอบด้วยวิธีที่เรียบง่ายและสวยงาม
  8. คุณสามารถรวม jUnit เข้ากับ Eclipse, Android Studio, Maven & Ant, Gradle และ Jenkins ได้

0

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


0

JUNIT: ตรวจสอบและปรับเปลี่ยน

นี่คือมุมมองของฉันเกี่ยวกับ JUNIT

JUNIT สามารถใช้เพื่อ
1) สังเกตพฤติกรรมของระบบเมื่อมีการเพิ่มหน่วยใหม่ในระบบนั้น
2) ทำการปรับเปลี่ยนในระบบเพื่อต้อนรับหน่วย "ใหม่" ในระบบ
อะไร? ตรง

ชีวิตจริงเช่น.

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

ในแง่การเขียนโปรแกรม

ระบบ: รหัสของคุณ
หน่วย : ฟังก์ชันใหม่
เนื่องจาก JUNIT framework ถูกใช้สำหรับภาษา JAVA ดังนั้น JUNIT = JAVA UNIT (อาจเป็น)

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

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

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