ข้อเสียของการทดสอบพัฒนาขับเคลื่อน? [ปิด]

ฉันจะสูญเสียอะไรบ้างโดยใช้การออกแบบขับเคลื่อนทดสอบ

แสดงรายการเชิงลบเท่านั้น ไม่แสดงรายการผลประโยชน์ที่เขียนในรูปแบบเชิงลบ

ข้อเสียหลายประการ (และฉันไม่ได้อ้างว่าไม่มีประโยชน์ - โดยเฉพาะอย่างยิ่งเมื่อเขียนรากฐานของโครงการ - มันจะช่วยประหยัดเวลาได้มากในตอนท้าย):

• ลงทุนครั้งใหญ่ สำหรับกรณีง่ายๆคุณสูญเสียการใช้งานจริงประมาณ 20% แต่สำหรับกรณีที่ซับซ้อนคุณจะสูญเสียอีกมาก
• ความซับซ้อนเพิ่มเติม สำหรับกรณีที่ซับซ้อนกรณีทดสอบของคุณยากต่อการคำนวณฉันขอแนะนำในกรณีเช่นนั้นเพื่อลองและใช้รหัสอ้างอิงอัตโนมัติที่จะทำงานแบบขนานในรุ่นดีบัก / ทดสอบการทำงานแทนที่จะทดสอบหน่วยกรณีที่ง่ายที่สุด
• ผลกระทบการออกแบบ บางครั้งการออกแบบไม่ชัดเจนในช่วงเริ่มต้นและวิวัฒนาการตามที่คุณไป - สิ่งนี้จะบังคับให้คุณทำการทดสอบซ้ำซึ่งจะทำให้เสียเวลามาก ฉันขอแนะนำให้เลื่อนการทดสอบหน่วยในกรณีนี้จนกว่าคุณจะเข้าใจการออกแบบ
• Tweaking อย่างต่อเนื่อง สำหรับโครงสร้างข้อมูลและการทดสอบหน่วยกล่องดำอัลกอริทึมจะสมบูรณ์แบบ แต่สำหรับอัลกอริทึมที่มีแนวโน้มที่จะเปลี่ยนแปลง tweaked หรือปรับจูนนี่อาจทำให้การลงทุนครั้งใหญ่ที่หนึ่งอาจเรียกร้องไม่เป็นธรรม ใช้งานเมื่อคุณคิดว่ามันเหมาะกับระบบจริง ๆ และไม่บังคับให้การออกแบบให้พอดีกับ TDD

หากคุณต้องการทำ TDD "ของจริง" (อ่าน: ทดสอบก่อนด้วยขั้นตอนสีแดงสีเขียว refactor) จากนั้นคุณต้องเริ่มใช้ mocks / stubs เมื่อคุณต้องการทดสอบจุดรวม

เมื่อคุณเริ่มใช้ mocks หลังจากระยะเวลาหนึ่งคุณจะต้องการเริ่มใช้ Dependency Injection (DI) และคอนเทนเนอร์ Inversion of Control (IoC) ในการทำเช่นนั้นคุณต้องใช้อินเทอร์เฟซสำหรับทุกสิ่ง (ซึ่งมีข้อผิดพลาดมากมาย)

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

และโปรดจำไว้ว่ารหัสทดสอบควรได้รับการดูแลและดูแลรักษาด้วย การทดสอบควรอ่านได้ทุกอย่างและใช้เวลาในการเขียนรหัสที่ดี

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

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

การทดสอบทั้งหมดเหล่านี้ทำให้ "เปลี่ยนแปลง" ยากขึ้นมาก (ตรงข้ามกับการปรับโครงสร้างใหม่) พฤติกรรมของระบบของคุณและการเปลี่ยนแปลงอย่างง่าย ๆ นั้นยากเกินไปและใช้เวลานาน

หากคุณอ่านวรรณกรรม TDD มีตัวอย่างที่ดีอยู่เสมอ แต่บ่อยครั้งในแอปพลิเคชันในชีวิตจริงคุณต้องมีส่วนต่อประสานผู้ใช้และฐานข้อมูล นี่คือที่ TDD ยากจริง ๆ และแหล่งข้อมูลส่วนใหญ่ไม่มีคำตอบที่ดี และถ้าพวกเขาทำมันมักเกี่ยวข้องกับ abstractions เพิ่มเติม: วัตถุจำลองการเขียนโปรแกรมไปยังอินเทอร์เฟซรูปแบบ MVC / MVP ฯลฯ ซึ่งต้องใช้ความรู้อีกครั้งและ ... คุณต้องเขียนโค้ดเพิ่มเติม

ดังนั้นระวัง ... ถ้าคุณไม่มีทีมกระตือรือร้นและนักพัฒนาที่มีประสบการณ์อย่างน้อยหนึ่งคนที่รู้วิธีการเขียนการทดสอบที่ดีและรู้บางสิ่งเกี่ยวกับสถาปัตยกรรมที่ดีคุณต้องคิดสองครั้งก่อนที่จะลงไปสู่ถนน TDD .

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

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

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

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

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

ดังนั้น (IMO) โดยย่อ:

• ระยะเวลาที่ใช้ในการคิด (เช่นจริง ๆ แล้วกำลังทำการทดสอบ )
• ความรู้ใหม่ที่จำเป็นในการรู้วิธีการเขียนรหัสที่สามารถทดสอบได้
• ทำความเข้าใจกับการเปลี่ยนแปลงทางสถาปัตยกรรมที่จำเป็นเพื่อให้โค้ดทดสอบได้
• การเพิ่มความสามารถของคุณของ "TDD-Coder" ในขณะที่พยายามพัฒนาทักษะอื่น ๆ ที่จำเป็นสำหรับการเขียนโปรแกรมที่มีชื่อเสียงของเรา :)
• การจัดระเบียบฐานรหัสของคุณเพื่อรวมรหัสทดสอบโดยไม่คาดคั้นรหัสผลิตของคุณ

  ---

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

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

ขายให้กับผู้บริหาร

TDD ทำได้ดีที่สุดในคู่ สำหรับหนึ่งมันเป็นเรื่องยากที่จะต่อต้านการกระตุ้นเพียงแค่เขียนการใช้งานเมื่อคุณรู้วิธีการเขียนคำสั่งif / else แต่ทั้งคู่จะทำให้คุณทำงานเพราะคุณทำให้เขาทำงาน น่าเศร้าที่ บริษัท / ผู้จัดการหลายคนไม่คิดว่านี่เป็นการใช้ทรัพยากรอย่างคุ้มค่า ทำไมต้องจ่ายให้คนสองคนเขียนคุณสมบัติเดียวเมื่อฉันมีคุณสมบัติสองอย่างที่ต้องทำพร้อมกัน?

ขายให้นักพัฒนาอื่น ๆ

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

การบำรุงรักษารหัสทดสอบพร้อมกับรหัสการผลิตของคุณ

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

การเขียนการทดสอบเพื่อให้คุณครอบคลุมทุกอย่าง (ครอบคลุมรหัส 100%)

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

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

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

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

ในโครงการ TDD แรกของคุณมีการสูญเสียครั้งใหญ่สองครั้งเวลาและอิสรภาพส่วนบุคคล

คุณเสียเวลาเพราะ:

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

คุณสูญเสียอิสรภาพส่วนบุคคลเพราะ:

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

หวังว่านี่จะช่วยได้

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

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

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

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

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

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

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

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

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

ข้อเสียของ TDD คือมันมักจะเชื่อมโยงอย่างแน่นหนากับวิธีการ 'Agile' ซึ่งไม่มีความสำคัญในการจัดทำเอกสารของระบบแทนที่จะเข้าใจว่าทำไมการทดสอบ 'จึงควรคืนค่าหนึ่งค่าแทนที่จะเป็นค่าอื่น ๆ ที่อยู่ในนักพัฒนาเท่านั้น ศีรษะ.

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

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

ฉันได้พบกับหลายสถานการณ์ที่ TDD ทำให้ฉันเป็นบ้า ในการตั้งชื่อบางอย่าง:

• การบำรุงรักษากรณีทดสอบ:

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

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

• ทดสอบความซับซ้อนอัตโนมัติ:

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

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

ปัญหาที่ใหญ่ที่สุดคือคนที่ไม่รู้วิธีเขียนการทดสอบหน่วยที่เหมาะสม พวกเขาเขียนการทดสอบที่ขึ้นอยู่กับแต่ละอื่น ๆ (และพวกเขาทำงานได้ดีกับ Ant แต่แล้วก็ล้มเหลวทั้งหมดเมื่อฉันเรียกใช้จาก Eclipse เพียงเพราะพวกเขาทำงานในลำดับที่แตกต่างกัน) พวกเขาเขียนการทดสอบที่ไม่ได้ทดสอบอะไรเป็นพิเศษ - พวกเขาเพียงแค่ทำการดีบั๊กตรวจสอบผลลัพธ์และเปลี่ยนเป็นการทดสอบโดยเรียกมันว่า "test1" พวกเขาขยายขอบเขตของคลาสและวิธีการเพียงเพราะมันจะง่ายต่อการเขียนการทดสอบหน่วยสำหรับพวกเขา รหัสของการทดสอบหน่วยเป็นเรื่องที่แย่มากกับปัญหาการเขียนโปรแกรมแบบดั้งเดิมทั้งหมด (การมีเพศสัมพันธ์อย่างหนักวิธีการที่มีความยาว 500 บรรทัดค่าฮาร์ดโค้ดการทำสำเนารหัส) และเป็นสิ่งที่ต้องดูแล ด้วยเหตุผลแปลก ๆ บางอย่างที่ผู้คนปฏิบัติต่อการทดสอบหน่วยเป็นสิ่งที่ด้อยกว่ารหัส "ของจริง" และพวกเขาก็ไม่ ' ไม่ใส่ใจเกี่ยวกับคุณภาพของพวกเขาเลย :-(

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

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

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

คุณสูญเสียความสามารถในการบอกว่าคุณ "เสร็จสิ้น" ก่อนที่จะทดสอบโค้ดทั้งหมดของคุณ

คุณสูญเสียความสามารถในการเขียนโค้ดนับร้อยหรือพันเส้นก่อนเรียกใช้

คุณเสียโอกาสในการเรียนรู้ผ่านการดีบัก

คุณสูญเสียความยืดหยุ่นในการจัดส่งรหัสที่คุณไม่แน่ใจ

คุณสูญเสียอิสรภาพในการเพิ่มโมดูลของคุณให้แน่น

คุณสูญเสียตัวเลือกในการข้ามการเขียนเอกสารการออกแบบระดับต่ำ

คุณสูญเสียความมั่นคงที่มาพร้อมกับรหัสที่ทุกคนกลัวที่จะเปลี่ยนแปลง

ฉันสองคำตอบเกี่ยวกับเวลาการพัฒนาเริ่มต้น นอกจากนี้คุณยังสูญเสียความสามารถในการทำงานอย่างปลอดภัยโดยไม่ต้องทดสอบความปลอดภัย ฉันยังถูกอธิบายว่าเป็น nutbar TDD ดังนั้นคุณอาจสูญเสียเพื่อนสองสามคน;)

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

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

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

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

อาจเป็นเรื่องยากและเสียเวลาในการทดสอบการเขียนข้อมูล "สุ่ม" เช่นฟีด XML และฐานข้อมูล (ไม่ใช่เรื่องยาก) ฉันใช้เวลาพอสมควรในการทำงานกับฟีดข้อมูลสภาพอากาศ มันค่อนข้างสับสนสำหรับการทดสอบการเขียนอย่างน้อยก็เพราะฉันไม่มีประสบการณ์กับ TDD มากเกินไป

คุณจะสูญเสียชั้นเรียนขนาดใหญ่ที่มีความรับผิดชอบหลายอย่าง คุณอาจสูญเสียวิธีการขนาดใหญ่ที่มีความรับผิดชอบหลายอย่าง คุณอาจสูญเสียความสามารถในการ refactor แต่คุณจะสูญเสียความต้องการ refactor

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

ฉันบอกว่าสิ่งนี้ชี้ให้เห็นถึงสิ่งที่เป็นนามธรรมที่ไม่ได้รับ - หากจำเป็นต้องทดสอบรหัสส่วนตัวจริง ๆ ก็น่าจะเป็นในชั้นเรียนที่แยกต่างหาก

เดฟแมนน์

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

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

TDD เป็นทักษะที่นักพัฒนาเยาวชนอาจต้องต่อสู้ในตอนแรก (ส่วนใหญ่เป็นเพราะพวกเขาไม่ได้รับการสอนให้ทำงานด้วยวิธีนี้)

โดยรวมแม้ว่าข้อเสียจะได้รับการแก้ไขเมื่อผู้คนมีทักษะและคุณจบลงด้วยการย่อโค้ด 'เหม็น' และมีระบบที่เสถียรกว่า

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

• การทดสอบหน่วยเป็นรหัสเพิ่มเติมในการเขียนจึงมีค่าใช้จ่ายในการพัฒนาสูงขึ้น
• มันเป็นรหัสเพิ่มเติมในการรักษา
• ต้องเรียนรู้เพิ่มเติม

คำตอบที่ดีทั้งหมด ฉันจะเพิ่มสองสามวิธีเพื่อหลีกเลี่ยงด้านมืดของ TDD:

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

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

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

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

เมื่อรหัสเปลี่ยนแปลงคุณต้องเปลี่ยนการทดสอบเช่นกัน ด้วยการปรับโครงสร้างใหม่นี้อาจเป็นงานพิเศษจำนวนมาก

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

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

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

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

คนที่สอนการพัฒนาทีมของฉันเปรียวไม่เชื่อในการวางแผนคุณเขียนเท่าที่ต้องการน้อยที่สุด

คำขวัญของเขาคือ refactor, refactor, refactor ฉันเข้าใจว่า refactor หมายถึง 'ไม่ได้วางแผนล่วงหน้า'

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