TDD / ทดสอบภาระค่าใช้จ่าย / การบำรุงรักษามากเกินไปหรือไม่

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

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

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

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

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

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

การพยายามในรูปแบบของ TDD จะทำให้ฝันร้ายเป็นเรื่องการบำรุงรักษาและเป็นไปไม่ได้สำหรับทีมที่จะรักษา

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

วิธีเดียวที่จะทำให้จุดนี้คือการมีรหัสที่มีต้นทุนต่ำในการรักษา

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

ทุกคนพูดแบบนี้ มันอาจเป็นจริงบางส่วนเช่นกัน ถ้าแอพพลิเคชั่นนั้นได้รับการออกแบบมาอย่างดีพอสมควร Front-end ก็จะมีน้อยมาก

ถ้าแอปพลิเคชันได้รับการออกแบบไม่ดี Front-end จะทำงานหนักเกินไปและทดสอบได้ยาก นี่เป็นปัญหาการออกแบบไม่ใช่ปัญหาการทดสอบ

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

นี่คืออาร์กิวเมนต์เดียวกันกับข้างต้น

คุณไม่สามารถโต้แย้งได้ ดังนั้นอย่าเถียง

"ฉันรับผิดชอบเต็มที่ในการเขียนผลิตภัณฑ์นี้ใหม่"

ในกรณีนั้น,

1. เพิ่มการทดสอบต่อไป แต่เพิ่มการทดสอบตามที่คุณไปทีละน้อย อย่าใช้เวลานานในการเขียนข้อสอบก่อน แปลงนิดหน่อย ทดสอบนิดหน่อย แปลงเพิ่มอีกนิด ทดสอบอีกหน่อย

2. ใช้การทดสอบเหล่านั้นจนกว่าจะมีคนคิดว่าการทดสอบใช้งานได้และถามว่าทำไมสิ่งต่าง ๆ ถึงดี

ฉันมีข้อโต้แย้งเดียวกันกับการเขียนใหม่ (จาก C ++ ถึง Java) และฉันก็ใช้การทดสอบแม้ว่าพวกเขาจะบอกว่าไม่

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

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

ไม่มีใครจำเป็นต้องรู้รายละเอียดว่าทำไมคุณถึงประสบความสำเร็จ

เพิ่งจะประสบความสำเร็จ

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

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

คุณต้องปฏิบัติเกี่ยวกับสิ่งเหล่านี้ได้ TDD เป็นสิ่งที่ดีที่มีอยู่ในทางทฤษฎี แต่ถ้าคุณไม่อัปเดตการทดสอบของคุณสำหรับทุกสิ่งที่เพิ่มเข้ามามีประเด็นเล็ก ๆ น้อย ๆ ในนั้น - ไม่มีใครอยากทำการทดสอบที่รายงาน รหัสเมื่อการทดสอบที่ไม่ได้รับการปรับปรุง! ผลก็คือมันอาจมีค่าใช้จ่ายสูงเกินไปในการทำเช่นนั้น - คุณจะไม่เป็นคนเดียวที่ทำงานกับโค้ดนั้น

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

โอกาสนี้เป็นสาเหตุที่พวกเขา don t ดูแลการทดสอบหน่วย

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

PS ฉันเห็นคำถามอื่นของคุณที่คุณวิพากษ์วิจารณ์เลเยอร์สิ่งที่เป็นนามธรรมและที่นี่คุณวิพากษ์วิจารณ์การขาดตัวสร้าง DI! ทำให้ความคิดของคุณขึ้น :)

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

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

ใช่การบำรุงรักษาการทดสอบเป็นภาระ อัปเดตพวกเขาอัปเดตข้อมูลทดสอบของคุณ: ทั้งหมดนี้ทำให้คุณเสียเวลา

ทางเลือก - ทำการทดสอบด้วยตนเองกลั่นข้อบกพร่องที่ไม่สามารถบอกได้ว่าโค้ดของคุณทำงานในเวลาไม่กี่วินาทีซึ่งมีค่าใช้จ่ายมากขึ้น

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