การทดสอบหน่วยเก่า / มรดกที่ชำรุด

ฉันทำงานกับ บริษัท ใหญ่และฉันรับผิดชอบงานจาวาแอพพลิเคชั่นขนาดใหญ่ที่มีการทดสอบ Junit นับพัน ตั้งแต่ฉันย้ายไปที่บทนี้มีการทดสอบแตก 200-300 ครั้ง (น่าจะพังได้หลายปี) การทดสอบนั้นเก่าและเปราะบางและพวกเขากำลังยุ่งเหยิงของการพึ่งพาสปาเก็ตตี้ที่มักจะจบลงด้วยข้อมูลแซนด์บ็อกซ์สด

เป้าหมายของฉันคือการผ่านการทดสอบ 100% เพื่อให้เราสามารถสร้างความล้มเหลวในการสร้างหน่วยทดสอบ แต่ฉันไม่สามารถทำได้จนกว่าฉันจะจัดการกับการทดสอบที่เสียหาย ฉันมีงบประมาณน้อยมากเพราะงบประมาณการบำรุงรักษาเป็นสิ่งสำคัญสำหรับการสนับสนุน แต่ทีมของฉันได้ระบุและแก้ไขการทดสอบผลไม้แขวนลอยต่ำ (ส่วนใหญ่เป็นปัญหาการกำหนดค่า / ปัญหาทรัพยากรในท้องถิ่น) และเราลงไปทดสอบที่น่าเกลียด 30-40

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

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

อะไรคือแนวทางที่ดีที่สุด

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

สิ่งที่ฉันจะทำคือปิดการใช้งานการทดสอบครั้งแรกซึ่งล้มเหลวและมีอยู่เสมอล้มเหลว

ทำให้การทดสอบล้มเหลว

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

เมื่อคุณทราบว่าฟังก์ชันการทดสอบที่คุณสามารถกำหนดคือ

• เราสนใจเกี่ยวกับเรื่องนี้หรือไม่
• การทดสอบนี้มีความสำคัญเพียงใด

แล้วทำรายการลำดับความสำคัญ

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

ฉันจะทำต่อไปนี้:

1. พยายามระบุสิ่งที่การทดสอบที่ล้มเหลวกำลังพยายามตรวจสอบ

2. Triage - หากการทดสอบบางอย่างพยายามทดสอบสิ่งที่ไม่สำคัญเช่นสถานะ (เก่า) ของโลกให้ลบออก หากคุณตระหนักว่าบางคนกำลังพยายามตรวจสอบสิ่งที่สำคัญลองตรวจสอบว่าการทดสอบเหล่านั้นทำถูกต้องหรือไม่ หากพวกเขากำลังทดสอบไม่ถูกต้องทำให้พวกเขาทดสอบอย่างถูกต้อง

3. แก้ไขสิ่งที่ไม่ถูกต้องด้วยรหัสการผลิตของคุณทันทีที่คุณได้รับการทดสอบ

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

การทดสอบที่หัก 200-300 ครั้ง (อาจเสียหายได้หลายปี)

อุ๊ย! ฉันเผชิญกับสถานการณ์ที่คล้ายคลึงกันหนึ่งครั้ง แต่มีการทดสอบ 7 ครั้งล้มเหลวซึ่งทีมเริ่มเพิกเฉยต่อความจริงที่ว่าพวกเขาล้มเหลวเป็นเวลาหลายเดือนเนื่องจากความคิดที่ว่า

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

ฉันหมกมุ่นอยู่กับเป้าหมายที่คล้ายกันแม้ว่าฉันจะเป็นเพียงนักพัฒนารุ่นน้องในทีมเพราะฉันสังเกตเห็นกองพะเนินซึ่งการทดสอบเพิ่มเติมล้มเหลวในช่วงหลายเดือนที่ผ่านมา ฉันต้องการให้เราเปลี่ยนสิ่งเหล่านั้นจาก "คำเตือน" เป็นข้อผิดพลาดในการสร้าง (อาจค่อนข้างน่ารังเกียจสำหรับทีมอื่น ๆ )

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

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

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

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

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

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

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

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

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

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

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

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

สร้างแบบทดสอบใหม่ที่เกี่ยวข้องและขึ้นกับการเขียนโค้ดที่ยอดเยี่ยม