ค้นหากรณีศึกษาว่า TDD ปรับปรุงคุณภาพและ / หรือความเร็วในการพัฒนาอย่างไร [ปิด]

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

การศึกษา 4 โครงการใน IBM และ Microsoft ตีพิมพ์ในEmperical วิศวกรรมซอฟต์แวร์วารสาร

การศึกษาเชิงประจักษ์แสดงการพัฒนาแบบทดสอบที่ขับเคลื่อนได้ช่วยปรับปรุงคุณภาพ

กระดาษตีพิมพ์ครั้งแรกในรายงานสมุดรายวันวิศวกรรมซอฟต์แวร์ Empirical: "TDD ดูเหมือนจะใช้ในโดเมนต่าง ๆ และสามารถลดความหนาแน่นของข้อบกพร่องของซอฟต์แวร์ที่พัฒนาแล้วได้อย่างมากโดยไม่ลดประสิทธิภาพการทำงานอย่างมีนัยสำคัญของทีมพัฒนา" การศึกษาเปรียบเทียบ 4 โครงการที่ Microsoft และ IBM ที่ใช้ TDD กับโครงการที่คล้ายกันซึ่งไม่ได้ใช้ TDD ...

เอกสารประกอบด้วยกรณีศึกษา 1 กรณีที่ IBM และ 3 จาก Microsoft กรณีศึกษาแต่ละกรณีเปรียบเทียบสองทีมที่ทำงานกับผลิตภัณฑ์เดียวกันโดยใช้ภาษาและเทคโนโลยีการพัฒนาเดียวกันภายใต้ผู้จัดการระดับสูงกว่าเดิมมีเพียงทีมเดียวเท่านั้นที่ใช้การพัฒนาแบบทดสอบขับเคลื่อน (TDD) ไม่มีทีมใดที่รู้ว่าพวกเขาจะเป็นส่วนหนึ่งของการศึกษาในระหว่างรอบการพัฒนาของพวกเขา กรณีศึกษาของ IBM ติดตามทีมที่ทำการพัฒนาไดรเวอร์อุปกรณ์ เคสของ Microsoft ติดตามทีมที่ทำงานบน Windows, MSN และ Visual Studio

กระดาษอธิบายถึงแนวทางปฏิบัติ TDD ที่ทีมใช้เป็นเวิร์กโฟลว์แบบนาทีต่อนาทีเช่นเดียวกับเวิร์กโฟลว์ระดับงาน ...

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

ตรวจสอบสิ่งนี้อย่างแน่นอน: TDD พิสูจน์แล้ว! หรือมันคืออะไร?

... เมื่อ Phil Haack ประกาศว่าการวิจัยสนับสนุนประสิทธิผลของ TDDฉันสนใจมากกว่าเล็กน้อยในการดูว่ารายงานที่เชื่อมโยงมีอยู่จริง คำพูดของฟิลจากนามธรรม

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

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

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

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

ผู้เขียนมีจุดที่ดีมากมายเกี่ยวกับ TDD ซึ่งไม่ใช่สิ่งที่มีประสิทธิภาพ (IMO แม้จะถูกหลอกจนตาย)

ดูเวลาที่คุณและลูกค้าใช้เวลาทดสอบซอฟต์แวร์ด้วยตนเอง เปรียบเทียบกับการประมาณระยะเวลาของการทดสอบอัตโนมัติสไตล์ TDD กระเป๋าความแตกต่าง

จากประสบการณ์ของฉันการทดสอบอัตโนมัติของ TDD เป็นทองคำเพราะพวกเขาให้การประกันและกำจัดการทดสอบด้วยตนเองจำนวนมหาศาล

ดังที่ Andres F ชี้ให้เห็นคุณจะได้รับประโยชน์เหล่านี้จากการทดสอบอัตโนมัติเท่านั้นไม่จำเป็นต้องใช้ TDD - อย่างไรก็ตาม TDD ต้องการการทดสอบอัตโนมัติแทนที่จะเป็นการทดสอบทีหลังหรือเป็นการดี

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

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

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

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

(โดยส่วนตัวแล้วฉันคิดว่า TDD เป็นแฟชั่นฟังดูดีในทางทฤษฎี แต่ในทางปฏิบัติ ... ไม่ค่อยดีฉันพบว่าการทดสอบการรวมเป็นสิ่งสำคัญมากกว่า แต่อาจเป็นเพียงโครงการที่ซับซ้อนที่ฉันทำงาน)

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

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

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

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

ฉันมักจะทำต่อไปนี้:

• ฉันเก็บภาพได้ไม่นาน
• เพียง 1 ยืนยัน. ไม่มีรูเล็ตรัสเซีย
• ฉันทดสอบสถานการณ์เชิงลบและข้อยกเว้นเชิงบวก

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

ฉันหวังว่ามันจะช่วย