ฉันควรตั้งใจทำลายโครงสร้างเมื่อพบข้อบกพร่องในการผลิตหรือไม่

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

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

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

กลยุทธ์ของเราคือ:

ตรวจสอบในการทดสอบล้มเหลว @Ignore("fails because of Bug #1234")แต่คำอธิบายด้วย

ด้วยวิธีนี้การทดสอบอยู่ที่นั่น แต่งานสร้างไม่แตก

แน่นอนคุณสังเกตการทดสอบละเว้นในข้อผิดพลาด db ดังนั้น@Ignoreจะถูกลบออกเมื่อการทดสอบได้รับการแก้ไข นอกจากนี้ยังทำหน้าที่ตรวจสอบการแก้ไขข้อบกพร่องได้ง่าย

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

แน่นอนข้อผิดพลาดควรยังคงได้รับการแก้ไข แต่การกำหนดเวลาการแก้ไขเป็นการตัดสินใจทางธุรกิจและไม่ใช่ข้อกังวลของ dev จริงๆ ... สำหรับฉันเมื่อมีการบันทึกข้อผิดพลาดใน bug DB มันไม่ใช่ปัญหาของฉันจนกว่าเจ้าของลูกค้า / ผลิตภัณฑ์จะบอกฉันว่าพวกเขาต้องการแก้ไข .

เหตุใดคุณต้องการอนุญาตให้การสร้างสำเร็จด้วยข้อบกพร่องที่ทราบ

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

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

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

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

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

ฉันจะยืนยันว่าควรเพิ่มการทดสอบที่ล้มเหลว แต่ไม่ชัดเจนว่าเป็น "การทดสอบที่ล้มเหลว"

@BenVoigt ชี้ให้เห็นในคำตอบของเขาการทดสอบที่ล้มเหลวไม่จำเป็นว่าจะต้อง "ทำลายโครงสร้าง" ฉันเดาว่าคำศัพท์อาจแตกต่างกันไปในแต่ละทีม แต่รหัสยังคงรวบรวมและผลิตภัณฑ์ยังสามารถจัดส่งด้วยการทดสอบที่ล้มเหลว

สิ่งที่คุณควรถามตัวเองในสถานการณ์เช่นนี้คือ

การทดสอบหมายถึงอะไรที่จะทำให้สำเร็จ

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

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

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

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

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

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

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

การเขียนแบบทดสอบที่คุณรู้ว่าจะล้มเหลวจนกว่าข้อผิดพลาดจะได้รับการแก้ไขเป็นความคิดที่ดีมันเป็นพื้นฐานของ TDD

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

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

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

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

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

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

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

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

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

คุณไม่ต้องการช่วยให้ทีมของคุณเข้าใจ

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

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

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

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