thetalkingwalnut ถามว่า:
อะไรคือวิธีที่ดีในการโน้มน้าวผู้พัฒนาที่สงสัยในทีมของการทดสอบหน่วย?
ทุกคนที่นี่จะมีเหตุผลมากมายออกมาจากสีน้ำเงินว่าทำไมการทดสอบหน่วยถึงดี อย่างไรก็ตามฉันพบว่าบ่อยครั้งวิธีที่ดีที่สุดในการโน้มน้าวใจใครบางคนคือการฟังการโต้เถียงของพวกเขาและพูดคุยแบบชี้ตรง หากคุณฟังและช่วยให้พวกเขาพูดแสดงความกังวลของพวกเขาคุณสามารถพูดคุยกับแต่ละคนและเปลี่ยนพวกเขาให้เป็นมุมมองของคุณ ใครจะรู้? บางทีพวกเขาจะโน้มน้าวคุณว่าทำไมการทดสอบหน่วยไม่เหมาะกับสถานการณ์ของคุณ ไม่น่าเป็นไปได้ แต่เป็นไปได้ บางทีถ้าคุณโพสต์ข้อโต้แย้งจากการทดสอบหน่วยเราสามารถช่วยระบุข้อโต้แย้งได้
เป็นเรื่องสำคัญที่จะต้องฟังและเข้าใจการโต้แย้งทั้งสองด้าน หากคุณพยายามใช้การทดสอบหน่วยด้วยความกระตือรือร้นโดยไม่คำนึงถึงความกังวลของผู้อื่นคุณจะจบลงด้วยสงครามศาสนา (และอาจเป็นการทดสอบยูนิตที่ไร้ค่าจริงๆ) หากคุณนำมาใช้อย่างช้าๆและเริ่มต้นด้วยการนำไปใช้ที่ซึ่งคุณจะเห็นประโยชน์มากที่สุดสำหรับค่าใช้จ่ายที่น้อยที่สุดคุณอาจแสดงให้เห็นถึงคุณค่าของการทดสอบหน่วยและมีโอกาสที่ดีกว่าในการโน้มน้าวผู้คน ฉันรู้ว่าสิ่งนี้ไม่ง่ายอย่างที่คิด - โดยปกติแล้วจะต้องใช้เวลาและตัวชี้วัดที่รอบคอบในการสร้างข้อโต้แย้งที่น่าเชื่อถือ
การทดสอบหน่วยเป็นเครื่องมือเหมือนอย่างอื่นและควรนำไปใช้ในลักษณะที่ประโยชน์ (การจับบั๊ก) มีค่าเกินกว่าค่าใช้จ่าย (ความพยายามในการเขียน) อย่าใช้พวกเขาหาก / ที่พวกเขาไม่สมเหตุสมผลและจำไว้ว่าพวกเขาเป็นเพียงส่วนหนึ่งของเครื่องมือคลังแสงของคุณ (เช่นการตรวจสอบการยืนยันการวิเคราะห์โค้ดวิธีที่เป็นทางการ ฯลฯ ) สิ่งที่ฉันบอกนักพัฒนาของฉันคือ:
พวกเขาสามารถข้ามการเขียนการทดสอบสำหรับวิธีการถ้าพวกเขามีข้อโต้แย้งที่ดีว่าทำไมมันไม่จำเป็น (เช่นง่ายเกินไปที่จะคุ้มค่าหรือยากเกินไปที่จะคุ้มค่า) และวิธีการที่จะตรวจสอบวิธีอื่น (เช่นการตรวจสอบการยืนยัน วิธีการอย่างเป็นทางการการทดสอบแบบโต้ตอบ / บูรณาการ) พวกเขาจำเป็นต้องพิจารณาว่าการตรวจสอบบางอย่างเช่นการตรวจสอบและการพิสูจน์อย่างเป็นทางการจะทำในเวลาและจากนั้นจะต้องทำซ้ำทุกครั้งที่มีการเปลี่ยนแปลงรหัสการผลิตในขณะที่การทดสอบหน่วยและยืนยันสามารถใช้เป็นการทดสอบการถดถอย ) บางครั้งฉันเห็นด้วยกับพวกเขา แต่บ่อยครั้งฉันจะถกเถียงกันว่าวิธีการนั้นง่ายเกินไปหรือยากเกินกว่าที่จะทดสอบหน่วย
หากผู้พัฒนาระบุว่าวิธีการนั้นง่ายเกินไปที่จะล้มเหลวคุณไม่จำเป็นต้องใช้เวลา 60 วินาทีในการเขียนการทดสอบหน่วย 5 บรรทัดอย่างง่าย ๆ ใช่ไหม โค้ด 5 บรรทัดเหล่านี้จะทำงานทุกคืน (คุณสร้างตอนกลางคืนใช่ไหม?) สำหรับปีถัดไปหรือมากกว่านั้นและจะคุ้มค่ากับความพยายามหากแม้เพียงครั้งเดียวที่มันเกิดขึ้นเพื่อจับปัญหาที่อาจใช้เวลา 15 นาทีหรือนานกว่านั้น และแก้ปัญหา นอกจากนี้การเขียนการทดสอบหน่วยง่าย ๆ ก็เพิ่มจำนวนการทดสอบหน่วยซึ่งทำให้นักพัฒนาดูดี
ในทางกลับกันหากผู้พัฒนาระบุว่าวิธีการทดสอบหน่วยยากเกินไป (ไม่คุ้มค่ากับความพยายามอย่างมีนัยสำคัญที่จำเป็น) บางทีอาจเป็นข้อบ่งชี้ที่ดีว่าวิธีการนั้นจำเป็นต้องแบ่งหรือ refactored เพื่อทดสอบชิ้นส่วนที่ง่าย โดยปกติแล้วนี่คือวิธีการที่ใช้ทรัพยากรที่ผิดปกติเช่นซิงเกิลตันเวลาปัจจุบันหรือทรัพยากรภายนอกเช่นชุดผลลัพธ์ฐานข้อมูล วิธีการเหล่านี้มักจะต้องมีการ refactored เป็นวิธีการที่ได้รับทรัพยากร (เช่นเรียก getTime ()) และวิธีการที่ใช้ทรัพยากรเป็นอาร์กิวเมนต์ (เช่นใช้เวลาประทับเป็นพารามิเตอร์) ฉันปล่อยให้พวกเขาข้ามการทดสอบวิธีการดึงทรัพยากรและพวกเขาแทนเขียนทดสอบหน่วยสำหรับวิธีการที่ใช้ทรัพยากรเป็นอาร์กิวเมนต์ โดยปกติแล้วสิ่งนี้ทำให้การเขียนการทดสอบหน่วยง่ายกว่าและคุ้มค่าที่จะเขียน
นักพัฒนาจำเป็นต้องวาด "เส้นในทราย" ในการทดสอบหน่วยของพวกเขาควรจะครอบคลุม ต่อมาในการพัฒนาเมื่อใดก็ตามที่เราพบข้อผิดพลาดพวกเขาควรตรวจสอบว่าการทดสอบหน่วยที่ครอบคลุมมากขึ้นจะได้พบปัญหา หากเป็นเช่นนั้นหากข้อบกพร่องดังกล่าวเกิดขึ้นซ้ำ ๆ พวกเขาจำเป็นต้องย้าย "บรรทัด" ไปยังการเขียนการทดสอบหน่วยที่ครอบคลุมมากขึ้นในอนาคต (เริ่มต้นด้วยการเพิ่มหรือขยายการทดสอบหน่วยสำหรับข้อบกพร่องปัจจุบัน) พวกเขาต้องการค้นหาสมดุลที่เหมาะสม
สิ่งสำคัญคือการตระหนักถึงการทดสอบหน่วยไม่ใช่กระสุนเงินและมีสิ่งดังกล่าวเป็นการทดสอบหน่วยมากเกินไป ที่ทำงานของฉันเมื่อใดก็ตามที่เราเรียนรู้บทเรียนฉันย่อมได้ยิน "เราจำเป็นต้องเขียนบททดสอบเพิ่มเติม" ฝ่ายบริหารพยักหน้าเห็นด้วยเพราะมันถูกกระแทกเข้ากับหัวของพวกเขาว่า "การทดสอบหน่วย" == "ดี"
อย่างไรก็ตามเราจำเป็นต้องเข้าใจผลกระทบของ "การทดสอบหน่วยเพิ่มเติม" ผู้พัฒนาสามารถเขียนโค้ดได้เพียงบรรทัดเดียว ~ N บรรทัดต่อสัปดาห์และคุณจำเป็นต้องทราบว่าเปอร์เซ็นต์ของรหัสนั้นควรเป็นหน่วยทดสอบโค้ดเทียบกับรหัสการผลิต สถานที่ทำงานหละหลวมอาจมีรหัส 10% ของการทดสอบหน่วยและ 90% ของรหัสเป็นรหัสการผลิตทำให้เกิดผลิตภัณฑ์ที่มีคุณสมบัติมากมาย (แม้ว่าจะเป็นรถบั๊กกี้) (คิดว่า MS Word) ในทางกลับกันร้านค้าที่เข้มงวดที่มีการทดสอบยูนิต 90% และรหัสการผลิต 10% จะมีผลิตภัณฑ์ที่แข็งแกร่งซึ่งมีคุณสมบัติน้อยมาก (คิดว่า "vi") คุณอาจไม่เคยได้ยินรายงานเกี่ยวกับการขัดข้องของผลิตภัณฑ์หลัง แต่ที่น่าจะเกี่ยวข้องกับผลิตภัณฑ์ที่ไม่ได้ขายดีเท่าที่เกี่ยวข้องกับคุณภาพของรหัส
ยิ่งไปกว่านั้นบางทีความมั่นใจเพียงอย่างเดียวในการพัฒนาซอฟต์แวร์ก็คือ "การเปลี่ยนแปลงหลีกเลี่ยงไม่ได้" สมมติว่าร้านค้าที่เข้มงวด (90% การทดสอบหน่วย / รหัสการผลิต 10%) สร้างผลิตภัณฑ์ที่มีคุณสมบัติ 2 ประการ (สมมติว่า 5% ของรหัสการผลิต == 1 คุณสมบัติ) หากลูกค้าเข้ามาและเปลี่ยน 1 ของคุณสมบัติการเปลี่ยนแปลงนั้นจะทำให้รหัส 50% ของรหัสหายไป (45% ของการทดสอบหน่วยและ 5% ของรหัสการผลิต) ร้านค้าหละหลวม (ทดสอบ 10% หน่วย / รหัสการผลิต 90%) มีผลิตภัณฑ์ที่มีคุณสมบัติ 18 อย่างซึ่งไม่ได้ผลดีมาก ลูกค้าของพวกเขาปรับปรุงข้อกำหนดสำหรับฟีเจอร์ 4 อย่างสมบูรณ์ แม้ว่าการเปลี่ยนแปลงจะมีขนาดใหญ่ขึ้น 4 เท่า แต่เพียงครึ่งเดียวของฐานรหัสจำนวนมากจะถูกทิ้งในถังขยะ (~ 25% = ~ 4.4% การทดสอบหน่วย + 20% ของรหัสการผลิต)
ประเด็นของฉันคือคุณต้องสื่อสารว่าคุณเข้าใจความสมดุลระหว่างการทดสอบหน่วยน้อยเกินไปและมากเกินไป - โดยพื้นฐานแล้วคุณคิดว่าผ่านทั้งสองด้านของปัญหา หากคุณสามารถโน้มน้าวใจเพื่อนร่วมงานและ / หรือการจัดการของคุณคุณจะได้รับความน่าเชื่อถือและอาจมีโอกาสที่ดีกว่าในการชนะพวกเขา