ค่าของการตรวจสอบในการทดสอบหน่วยที่ล้มเหลวคืออะไร?

ในขณะที่มีวิธีการป้องกันการทดสอบหน่วยจากการถูกดำเนินการอะไรคือค่าของการตรวจสอบในการทดสอบหน่วยที่ล้มเหลว?

ฉันจะใช้ตัวอย่างง่ายๆ: Case Sensitivity รหัสปัจจุบันคำนึงถึงขนาดตัวพิมพ์ อินพุตที่ถูกต้องลงในเมธอดคือ "Cat" และจะส่งคืน enum ของ Animal อย่างไรก็ตามฟังก์ชั่นที่ต้องการของวิธีการไม่ควรคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ ดังนั้นหากวิธีการที่อธิบายไว้ถูกส่งผ่าน "cat" มันอาจจะส่งคืนบางอย่างเช่น Animal.Null แทน Animal.Cat และการทดสอบหน่วยจะล้มเหลว แม้ว่าการเปลี่ยนรหัสอย่างง่ายจะทำให้งานนี้เกิดปัญหาที่ซับซ้อนมากขึ้นอาจใช้เวลาหลายสัปดาห์ในการแก้ไข แต่การระบุข้อบกพร่องด้วยการทดสอบหน่วยอาจเป็นงานที่ซับซ้อนน้อยกว่า

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

มูลค่าของการตรวจสอบในการทดสอบหน่วยที่ใช้บั๊กจนกว่าจะมีใครสามารถแก้ไขโค้ดได้

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

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

ฉันไม่ชอบ unittests ที่เช็คอินเพราะพวกเขาสร้างเสียงที่ไม่จำเป็น หลังจากทุก unittest ฉันจะต้องตรวจสอบปัญหาล้มเหลวทั้งหมด (สีแดง) เป็นสีแดงหรือไม่เนื่องจากมีปัญหาใหม่หรือมีการเปิดเก่าที่ต้องทำ / แก้ไข นี่มันไม่เป็นไรถ้ามี unittests มากกว่า 20 อัน

ฉันใช้แทน

• [Ignore("Reason")]คุณลักษณะที่ทำให้ผลลัพธ์เป็นสีเหลืองหรือ
• throw new NotImplementedException()ที่ทำให้ผลลัพธ์เป็นสีเทา

หมายเหตุ: ฉันกำลังใช้ NUnit สำหรับ. net ฉันไม่แน่ใจว่าคุณสมบัติ "สีเทา" นั้นมีอยู่ในกรอบการทำงานอื่น ๆ หรือไม่

ดังนั้นฉันจึงชอบความหมายของผลการทดสอบหน่วยต่อไปนี้

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

สามารถตรวจสอบทุกอย่างยกเว้น "สีแดง"

ในการตอบคำถาม: มีอันตรายเกินกว่าค่าที่จะเช็คอิน "red-failed-testes" แต่การตรวจสอบใน "การทดสอบที่ไม่สนใจสีเหลือง" หรือ "gray-NotImplementedYet-test" สามารถใช้เป็นรายการสิ่งที่ต้องทำ

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

ฉันคิดว่าสิ่งหนึ่งที่ควรพิจารณาคือนโยบายการพัฒนาของคุณอนุญาตให้ทำการทดสอบที่ล้มเหลวโดยไม่มีการลงโทษหรือไม่ ฉันมีเพื่อนที่ทำงานที่ร้านค้าที่ทำการพัฒนาแบบทดสอบเพื่อให้พวกเขาเริ่มต้นด้วยการทดสอบที่ล้มเหลวเสมอ ...

การทดสอบหน่วยที่ล้มเหลวจะทำให้ทีมพัฒนามองเห็นสิ่งที่ต้องทำเพื่อให้เป็นไปตามข้อกำหนดที่ตกลงกันไว้

กล่าวโดยย่อการทดสอบหน่วยที่ล้มเหลวทำให้ทีมมีรายการ "สิ่งที่ต้องทำ"

ด้วยเหตุนี้ความล้มเหลวในการทดสอบหน่วยอยู่ไกลดีกว่าไม่มีการทดสอบหน่วยที่ทุกคน. *
กรณีที่ไม่มีการทดสอบหน่วยใบทีมพัฒนาในที่มืด; รายละเอียดจะต้องได้รับการยืนยันซ้ำ ๆด้วยตนเอง

[* ให้ว่าหน่วยทดสอบจริงทดสอบสิ่งที่มีประโยชน์]

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

นี่คือย่อหน้าจากจุดเริ่มต้นของบทที่ 13 ของการทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดก :

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

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

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

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

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

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

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

วิธีที่ฉันเห็น TDD ที่ทำด้วยการใช้การทดสอบสำหรับรหัสที่ยังไม่เสร็จคือเขียนการทดสอบครั้งแรกด้วยแอตทริบิวต์ [ExpectedException] หรือคล้ายกัน สิ่งนี้ควรผ่านในขั้นต้นเนื่องจากรหัสที่ไม่สมบูรณ์จะไม่มีตรรกะใด ๆ ในนั้นและเขียนรหัสการยกเว้นใหม่ () แม้ว่าการผ่านข้อยกเว้นจะผิด แต่อย่างน้อยก็จะทำให้การทดสอบผ่านในขั้นต้นและเหมาะสำหรับการเช็คอิน เราอาจลืมการทดสอบที่ไม่สนใจ แต่อาจเป็นระเบียบเรียบร้อยหรือเติมรหัสที่ไม่สมบูรณ์ เมื่อเราทำเช่นนั้นการทดสอบที่สอดคล้องกันโดยอัตโนมัติซึ่งคาดว่าจะมีการคัดออกจะเริ่มล้มเหลวและเตือนให้คุณแก้ไข สิ่งนี้อาจเกี่ยวข้องกับการเปลี่ยนแปลงเล็กน้อยของการทดสอบเพื่อกำจัด ExpectException และทำการยืนยันจริงแทน CI, Dev, ผู้ทดสอบและลูกค้าทุกคนมีความสุขและเป็นสถานการณ์ที่ชนะ?