การทดสอบหน่วยใช้เป็นเอกสารจริงๆหรือไม่

ฉันไม่สามารถนับจำนวนครั้งที่ฉันอ่านข้อความในหลอดเลือดดำของ 'การทดสอบหน่วยเป็นแหล่งสำคัญของเอกสารของรหัสภายใต้การทดสอบ' ฉันไม่ปฏิเสธพวกเขาจริง

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

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

พวกเขาไม่ใช่เอกสารอ้างอิง ABSOLUTE

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

ดังนั้นในท้ายที่สุดวิธีที่ดีที่สุดที่จะเข้าใจรหัสคือการมีรหัสการทำงานที่สามารถอ่านได้

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

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

แต่พวกเขายังคงเติมเต็มเอกสารประกอบที่เป็นประโยชน์

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

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

Plus ถ้าเขียนใช้ BDD สไตล์ที่พวกเขาให้ความหมายที่ค่อนข้างดีของการทำสัญญาของชั้น เปิด IDE ของคุณ (หรือใช้ grep) เพื่อดูเฉพาะชื่อเมธอดและธาดา: คุณมีรายการพฤติกรรม

การถดถอยและข้อบกพร่องจำเป็นต้องทดสอบด้วยเช่นกัน

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

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

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

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

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

พวกเขากำลังแทนที่เอกสารหรือไม่ เลขที่

เป็นภาคผนวกที่มีประโยชน์สำหรับเอกสารประกอบหรือไม่? ใช่.

ฉันเห็นการทดสอบหน่วยเป็น:

• วิธีในการพิสูจน์ว่าเอกสารนั้นถูกต้อง (สมมติว่าเอกสารนั้นตรงกับการใช้ API)
• วิธีสาธิตให้นักพัฒนาทราบวิธีการใช้คุณสมบัติเฉพาะ การทดสอบหน่วยการทดสอบหน่วย / ตัวเองมักจะมีขนาดเล็กพอที่หนึ่งสามารถเรียนรู้ได้อย่างรวดเร็วจากมัน
• และเห็นได้ชัดว่าพบข้อบกพร่องการถดถอย

เพื่อขยายบางพวกเขาสามารถมองว่าเป็นส่วนประกอบของเอกสารที่มีอยู่ แต่ไม่เป็นเอกสาร

ฉันจะตอบคำถามของคุณโดยถามคุณอีกคน

คุณทำงานกับ API / รูทีนใหม่บ่อยครั้งเพียงใดเมื่อคุณช่วยหาตัวอย่างโค้ดของสิ่งที่คุณพยายามใช้ หากคุณเปลี่ยนเป็น Google เพื่อค้นหาตัวอย่างโค้ดออนไลน์

นั่นคือเมื่อคุณจะใช้การทดสอบหน่วยเป็นเอกสาร

• ในความเป็นจริงการทดสอบหน่วยอาจเข้มงวดกว่าตัวอย่างรหัสปกติเล็กน้อยเนื่องจากคุณควรมีการทดสอบหลายรายการ (ตัวอย่าง)
• หวังว่าการทดสอบหน่วยของคุณจะแสดงการใช้งานที่เหมาะสม เช่นพวกเขาแสดงให้เห็นถึงการพึ่งพาที่จำเป็นทั้งหมดอย่างชัดเจนผ่านวัตถุปกติหรือวัตถุจำลอง (มิฉะนั้นพวกเขาไม่ได้ทดสอบหน่วยที่ดีโดยเฉพาะ)
• หมายเหตุ: หากความคิดเห็นของคุณหรือ "เอกสารปกติ" แสดงตัวอย่างรหัสแสดงว่าคุณละเมิดหลักการ DRY และตัวอย่างโค้ดเหล่านั้นสามารถกลายเป็นผิดได้อย่างง่ายดายเมื่อเวลาผ่านไปในขณะที่มีโอกาสน้อยกว่าอย่างมากจากการทดสอบหน่วยที่ดำเนินการเป็นประจำ
• หากการทดสอบหน่วยที่มีอย่างละเอียด (มักจะเป็นใหญ่ถ้า ) จากนั้นพวกเขาควรจะให้ข้อมูลเพิ่มเติม:
  • ทุกกรณีขอบที่รู้จักกันแสดงให้เห็นอย่างชัดเจน
  • ข้อยกเว้นที่คาดหวังทั้งหมดที่สามารถโยนได้
  • พบข้อบกพร่องทั้งหมดก่อนหน้านี้ (ซึ่งอาจมีประโยชน์มากกว่าเมื่อขยายหน่วยภายใต้การทดสอบกว่าเมื่อเขียนไคลเอ็นต์ใหม่สำหรับหน่วย)
  • กฎเกณฑ์ทางธุรกิจทั้งหมดที่เกี่ยวข้องกับหน่วย (ถ้ามี)

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

• ฉันอยากจะแนะนำว่าบ่อยครั้งที่การทดสอบตัวเองยังไม่ดีพอสำหรับวัตถุประสงค์ คำตอบอื่น ๆ ได้พาดพิงถึงการทดสอบที่:
  • ไม่สมบูรณ์
  • ทำให้เกิดความสับสน (ฉันเคยเห็นกรณีทดสอบที่ไม่ได้เรียกวิธีการทดสอบโดยตรง - คุณไปที่ระดับ 3/4 ลึกลงไปในสแต็คการโทรก่อนที่จะถูกเรียกใช้ )
  • เชย (โดยปกติการทดสอบจะล้มเหลวเมื่อการทดสอบล้าสมัย แต่ไม่เป็นเช่นนั้นเสมอไป)
• มักจะมีตัวอย่างของการใช้งานมากมายที่มีอยู่แล้วในรหัสการผลิตเมื่อใดก็ตามที่มีความต้องการตัวอย่างเกิดขึ้น
• หน่วยภายใต้การทดสอบเขียนดีมาก (การจัดทำเอกสารด้วยตนเอง) ว่าวิธีการไม่ต้องการตัวอย่าง ฉันหวังว่า!
• จากประสบการณ์ของฉันในฐานะโปรแกรมเมอร์เรามักจะกระตือรือร้นที่จะกระโดดลงไปที่ส่วนลึกและ RTFM ในวันอังคารหน้า ...
• เอกสารและความคิดเห็นที่ละเมิดหลักการ DRY

TL; DR Unit การทดสอบและความเห็นของ API เป็นส่วนเสริม - บางอย่างอธิบายไว้ในโค้ดได้ดีที่สุด

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

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

ตัวอย่าง: คุณมีเมธอด m (a, b)ที่ทำการคำนวณบางอย่าง เนื่องจากข้อกำหนดด้านความเข้ากันได้แบบย้อนหลังจะต้องมีอินพุตตัวพิมพ์เล็กa=0และและa=-1ถ้าbเป็น NULL การใส่ลงในความคิดเห็นนั้นซับซ้อนสลับซับซ้อนและมีแนวโน้มที่จะค้างหากความต้องการนั้นถูกลบในภายหลัง

ถ้าคุณทำทดสอบหน่วยบางอย่างที่ตรวจสอบการทำงานของm(0, NULL), m(-1, x)คุณจะได้รับประโยชน์หลายประการ:

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