การเขียนความคิดเห็น java doc สำหรับกรณีทดสอบหน่วย


11

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


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

คำตอบ:


8

สิ่งที่ฉันทำคือ JAVADOC-comment:

  • คลาสซึ่งบ่งชี้ว่าคลาสใดถูกทดสอบหน่วย (แม้ว่าฉันควรเห็นได้ชัดเนื่องจากวิธีปฏิบัติที่ดีที่สุดในเรื่องนั้นแสดงให้เห็นว่าชื่อของกรณีทดสอบควรเป็นชื่อของคลาส + "Test" หรือ + "TestCase") สิ่งนี้ทำได้โดยใช้ความคิดเห็น {@link XXXClass} JAVADOC

  • วิธีการที่ระบุวิธีการทดสอบ ({@link XXXClass # method1}) บางครั้งฉันจำเป็นต้องมีวิธีทดสอบหลายวิธีสำหรับหนึ่งวิธีของคลาสเพื่อทดสอบเส้นทางทั้งหมดอย่างถูกต้อง เมื่อมันเกิดขึ้นฉันเขียนหนึ่งบรรทัดเพิ่มเติมเพื่อระบุว่าฉันกำลังทดสอบข้างในทางใด (แต่ฉันไม่เคยหลงทางจากการประชุมแบบบรรทัดเดียวของฉัน)

นอกจากนั้นไม่มีความคิดเห็นอื่น หากต้องการรับความสนใจจากที่อื่น ๆ คุณอาจใช้บางอย่างเช่นCoberturaเพื่อสร้างกราฟิกครอบคลุมรหัสที่ดีและทำให้พวกเขามีความสุขในแบบนั้น :-)

หมายเหตุเพิ่มเติม: ฉันหมายถึงกรณีทดสอบหน่วยหากเรากำลังพูดถึงกรณีทดสอบการรวมระบบแล้วหนึ่งหรือสองบรรทัดเพิ่มเติมเพื่ออธิบายสิ่งที่เกิดขึ้นอาจจำเป็นจริง ๆ ...


1

ข้อกำหนดในการจัดทำเอกสารสำหรับรหัสใด ๆ นั้นครอบคลุมอย่างสมบูรณ์ในคำตอบสำหรับคำถามนี้: หัวหน้าของฉันต้องการคำอธิบายภาษาอังกฤษแบบบรรทัดต่อบรรทัดของรหัสของเรา

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


0

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

การทดสอบหน่วยสำหรับการทดสอบไม่ใช่สำหรับเอกสารประกอบ การใช้การทดสอบหน่วยเป็นเอกสารผิดและไม่ควรทำ


2
ฉันพบว่าชุดการทดสอบที่ดีมีประโยชน์อย่างมากในการทำเอกสารรหัส พวกเขาให้ดำเนินการอ้างอิงเกี่ยวกับวิธีรหัสของใครบางคนควรที่จะนำมาใช้พร้อมกับหลักฐานที่จะทำงานรหัสอย่างถูกต้องเมื่อมีการใช้วิธีการที่
Bill Michell

@Bill - ไม่มีข้อโต้แย้งในเรื่องนี้มันมีประโยชน์ มันไม่ได้แทนที่เอกสารที่ถูกต้อง
littleadv

ขึ้นอยู่กับผู้ชมสำหรับเอกสารของคุณ - แต่ในบางกรณีคุณถูกต้องแน่นอน
Bill Michell

1
จะเป็นการดีที่การทดสอบหน่วยไม่ควรเป็นเพียงเอกสารของระบบ - แต่ในโลกแห่งความจริง, 9 โครงการจาก 10 กำลังทำงานกับรหัสเดิมที่มันอาจจะถือว่าโชคดีที่ได้ใด ๆเอกสารใด ๆ และในกรณีนี้ฉันชอบชุดการทดสอบที่ใช้งานและผ่านการทดสอบมากกว่าหนึ่งเอกสารซึ่งอาจไม่ตรงกับรหัสจริงทั้งหมด (ใช่แม้แต่ Javadoc ก็สามารถทำได้)
PéterTörök

@ PéterTörökใช่ ... ฉันย้ายไปทำงานกับนายจ้างที่แตกต่างกันหลาย บริษัท ที่รู้จักกันดี รหัสดั้งเดิมมากมาย การทดสอบหน่วยเดียวที่เคยมี - สิ่งที่ฉันเขียน ดังนั้นคุณโชคดีมาก อย่าคิดว่าสิ่งที่คุณเห็นคือสิ่งที่เกิดขึ้นทุกที่ และแม้ว่าคุณจะมีการทดสอบหน่วย ... ใครบอกว่าพวกเขาถูกต้อง? ใครบอกว่าพวกเขาครอบคลุมสิ่งที่ควรทำ ใครบอกว่าผลลัพธ์ที่คาดหวังคืออะไร ทำไมคุณถึงคิดว่าการทดสอบหน่วยไม่ได้ซิงค์กัน? เพียงเพราะพวกเขา "ผ่าน" เรื่องไร้สาระ
littleadv
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.