วิธีการจูงใจเพื่อนร่วมงานให้เขียนการทดสอบหน่วย? [ปิด]

เรากำลังทำงานเกี่ยวกับผลิตภัณฑ์ขนาดใหญ่ที่ได้รับการผลิตประมาณ 5 ปี codebase นั้น .. กำลังทำงานอยู่ ไม่ค่อยดี แต่มันใช้งานได้ ฟีเจอร์ใหม่ ๆ จะถูกนำไปผลิตและทดสอบด้วย QA ขนาดเล็ก ข้อบกพร่องได้รับการแก้ไข ฯลฯ แต่ไม่มีใครยกเว้นฉันเขียนการทดสอบหน่วย ไม่มีใครใช้พลังของ "การติดตาม" ข้อบกพร่องลงโดยการเขียนการทดสอบหน่วยเพื่อให้แน่ใจว่าข้อผิดพลาดพิเศษ (กรณีทดสอบ) นี้จะไม่เกิดขึ้นอีกเลย

ฉันได้คุยกับฝ่ายบริหาร ฉันได้พูดคุยกับนักพัฒนา ฉันได้พูดคุยกับทุกคนใน บริษัท ทั้งหมด ทุกคนพูดว่า: "ใช่เราต้องเขียนบททดสอบเพิ่มอีก!" ประมาณหนึ่งปีที่แล้ว ตั้งแต่นั้นมาฉันได้บังคับให้แนะนำการตรวจสอบโค้ดล่วงหน้า ( Gerrit ) และการรวมอย่างต่อเนื่อง ( Jenkins )

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

คำถามที่ 1: ฉันจะกระตุ้นเพื่อนร่วมงานให้เขียนการทดสอบหน่วยได้อย่างไร

Q2: ฉันจะยังคงมีแรงจูงใจในการปฏิบัติตามมาตรฐานคุณภาพรหัสส่วนตัวของฉันได้อย่างไร (บางครั้งมันน่าผิดหวังจริงๆ!)

PS: ข้อเท็จจริงที่น่าผิดหวังบางอย่าง (เข้าถึงได้ใน 1 ปี):

• การทดสอบหน่วยทั้งหมด: 1693
• ทั้งหมด "ตัวอย่างการทดสอบหน่วย": ประมาณ 50
• ทำโดยฉัน: 1521

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

แก้ไข 2:ตามคำตอบทั้งหมดฉันได้ทำรายการตรวจสอบขนาดเล็กสำหรับตัวเอง ฉันได้พูดคุยกับนักพัฒนาสองคนในแบบส่วนตัวและเรามีการพูดคุยที่ดีและซื่อสัตย์

หนึ่งในนั้นบอกฉันว่าเทลาสตินกล่าวว่าเขาอึดอัดกับการทดสอบหน่วย เขาบอกว่าเขาต้องการที่จะเป็น "มืออาชีพมากขึ้น" แต่เขาต้องการความเป็นอิสระ เขายังกล่าวด้วยว่าการประชุมทดสอบหน่วยของเรากับนักพัฒนาทั้งหมด (ประมาณ 9-11) นั้นดี แต่มันก็ค่อนข้างแออัด Meh นักวิจารณ์บางคนสำหรับฉัน แต่ฉันจะเรียนรู้จากสิ่งนั้น (ดูคำตอบด้านล่างเกี่ยวกับการประชุม tdd kata!)

อีกคนหนึ่งบอกว่าเขาไม่สนใจเขียนแบบทดสอบหน่วย เขาคิดว่างานของเขาดีพอสำหรับเงินเดือนของเขา เขาไม่ต้องการใช้ความพยายามมากขึ้นฉันพูดไม่ออกเลยทีเดียว ทั่วไป 9-5 "คนงาน"

สัปดาห์หน้าฉันจะคุยกับนักพัฒนาคนอื่น

ขอบคุณสำหรับคำตอบที่ดี (จนถึงตอนนี้) และการสนับสนุนของคุณ ฉันซาบซึ้งจริงๆ! ฉันได้เรียนรู้มากมายแล้วขอบคุณมาก!

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

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

เรื่องสั้นสั้น ๆ บางสถานการณ์เช่นนี้ปรากฏขึ้นและอีก 2 นักพัฒนากลายเป็น TDD / ผู้ที่ชื่นชอบการทดสอบ (ยังมีอีกไม่กี่ที่จะไป

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

• เครื่องคำนวณสตริงของ Roy
• ธนาคาร OCR

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

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

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

ผลลัพธ์ของตัวอย่างเหล่านั้นควรเป็นคำถามง่าย ๆ - ถ้าคุณสามารถใช้คุณลักษณะการพัฒนาx- ชั่วโมง Y ได้, ทำไมจะยืนยันในการทำแบบ2x ?

ก่อนอื่นคุณต้องรู้ว่าทำไมพวกเขาถึงไม่เขียนข้อสอบ

ตาราง dev ที่แน่นมักเป็นเหตุผล แต่คุณบอกว่าคุณไม่มี

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

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

ความเป็นไปได้ที่แข็งแกร่งอีกประการหนึ่งคือเพราะพวกเขาไม่เห็นคุณค่าใด ๆ สำหรับการทำงานมากขึ้นแม้ว่าพวกเขาจะให้บริการริมฝีปากกับความคิด

ดังนั้นคุณจะจัดการกับเหตุผลที่แตกต่างได้อย่างไร

เหตุผลที่หนึ่งง่ายแสดงตัวอย่างว่าประหยัดเวลาในการพัฒนาได้อย่างไร

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

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

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

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

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

ฉันจะเริ่มต้นด้วยการแสดงให้เห็นถึงประโยชน์ของ TDD พยายามแสดงประโยชน์ของการทดสอบหน่วย

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

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

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

การอ้างอิงที่ดีสำหรับการอ่านเพิ่มเติม:

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

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

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

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

นี้ดูเหมือนว่ากรณีใหญ่นำโดยตัวอย่าง

มีอยู่สองประการโดยธรรมชาติของธรรมชาติมนุษย์ที่คุณกำลังต่อสู้:

• คนที่สร้างสรรค์ไม่ชอบกระบวนการ
• คนส่วนใหญ่ไม่ชอบการตัดสินจากภายนอกเกี่ยวกับคุณภาพของพวกเขา

มันยากมากที่จะต่อสู้เรื่องนี้ด้วยการบรรยายประกาศการจัดการหรือตรรกะ คุณต้องชนะการใช้ประโยชน์จากแง่มุมอื่นของธรรมชาติของมนุษย์

• คนเลียนแบบพฤติกรรมของพนักงานที่ดีที่สุด

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

ถามพวกเขา.

คุณบอกว่ามีคนบอกและยอมรับว่าพวกเขาควรเขียนแบบทดสอบเพิ่มเติม ทำไมพวกเขาไม่?

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

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

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

ผู้ขายรายใหญ่รายที่สองคือวงจร QA ก่อนที่จะมีการเริ่มต้น TDD ใน บริษัท ของฉันเราจะผลักดันการเผยแพร่ใหม่ให้กับ QA เพื่อทดสอบทุกสัปดาห์ พวกเขาจะสร้างกองบักออกจากรีลีสนั้นเราแก้ไขบั๊กเหล่านั้นและผลักดันรีลีสอื่น ทำซ้ำจนกระทั่งเสร็จ โครงการแรกที่เราทำคือ TDD ไม่จำเป็นต้องผลักดันให้ QA จนกว่าจะผ่านไปหลายสัปดาห์ และจำนวนของแมลงที่พบนั้นน้อยมาก 10% เมื่อเทียบกับโครงการที่คล้ายกัน คุณมีวิธีรวบรวมสถิติเหล่านั้นสำหรับทีมของคุณหรือไม่?

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

สุดท้ายแสดงให้พวกเขาเห็นว่าพวกเขาจะสามารถสร้างรหัสใหม่ได้อย่างมั่นใจได้อย่างไร

เก็บทุกสิ่งไว้ในใจเมื่อคุณไม่รู้สึกอยากเขียนข้อสอบ :)

ฉันต้องการขยายคำตอบของ HLGEMโดยเฉพาะในส่วนนี้:

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

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

การพยายามทดสอบด้วยรหัสเก่าที่ไม่ได้เขียนด้วยการทดสอบอาจเป็นเรื่องที่น่าหงุดหงิด

ฉันใช้เทคนิคเล็กน้อย:

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

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

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

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