ประสบการณ์เชิงลบของ TDD [ปิด]

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

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

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

เช่นเดียวกับทุกสิ่งที่อยู่ภายใต้แบนเนอร์ "Agile" TDD เป็นสิ่งที่ฟังดูดีในทางทฤษฎี แต่ในทางปฏิบัติมันไม่ชัดเจนว่ามันดีแค่ไหน (และก็เหมือนกับสิ่งที่ "Agile" ส่วนใหญ่คุณจะได้รับการบอกว่าถ้าคุณไม่ ชอบมันคุณกำลังทำผิด)

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

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

บทสัมภาษณ์นี้ ( ผู้เขียนClojure ) Rich Hickeyมีดังต่อไปนี้ ฉันรู้สึกเห็นอกเห็นใจ 100%:

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

อีกข้อความที่คล้ายกันจาก Donald Knuth ในบทสัมภาษณ์Coders at Work book คัดลอกมาจากที่นี่ :

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

Knuth: เมื่อฉันเขียน TeX ครั้งแรกในปี 1977 และ '78 แน่นอนว่าฉันไม่มีการเขียนโปรแกรมเชิงความรู้ แต่ฉันมีการเขียนโปรแกรมที่มีโครงสร้าง ฉันเขียนมันลงในสมุดบันทึกเล่มใหญ่ด้วยดินสอ หกเดือนต่อมาหลังจากฉันผ่านโครงการทั้งหมดฉันเริ่มพิมพ์ลงในคอมพิวเตอร์ และทำการดีบั๊กในเดือนมีนาคมของปี 78 ในขณะที่ฉันเริ่มเขียนโปรแกรมในเดือนตุลาคมปี '77 รหัสสำหรับสิ่งนี้อยู่ในคลังเก็บของ Stanford ทุกอย่างใช้ดินสอและแน่นอนว่าฉันจะกลับมาและเปลี่ยนรูทีนย่อยตามที่ฉันได้เรียนรู้ว่าควรจะเป็นอะไร นี่เป็นระบบยุคแรกดังนั้นจึงมีสถาปัตยกรรมที่แตกต่างกันมากมายและต้องถูกทิ้งไว้จนกว่าฉันจะอยู่กับมันซักพักแล้วก็รู้ว่ามีอะไรบ้าง และมันเป็นปัญหาไก่และไข่ - คุณไม่สามารถเรียงพิมพ์จนกว่าคุณจะมีแบบอักษร แต่แล้วคุณก็จะไม่มีแบบอักษรจนกว่าคุณจะสามารถเรียงพิมพ์ได้ แต่การเขียนโปรแกรมที่มีโครงสร้างทำให้ฉันมีความคิดเกี่ยวกับค่าคงที่และรู้วิธีทำกล่องดำที่ฉันสามารถเข้าใจได้ ดังนั้นฉันจึงมั่นใจว่ารหัสจะทำงานเมื่อฉันจะแก้จุดบกพร่องในที่สุด ฉันรู้สึกว่าฉันจะประหยัดเวลาได้มากถ้าฉันรอหกเดือนก่อนทดสอบอะไร ฉันมีความมั่นใจมากพอที่รหัสจะถูกต้อง

Seibel: และประหยัดเวลาเพราะคุณจะไม่ใช้เวลาในการสร้างนั่งร้านและสตับเพื่อทดสอบโค้ดที่ไม่สมบูรณ์ใช่ไหม

Knuth: ถูกต้อง

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

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

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

ฉันไม่ได้เห็นมันเป็นการส่วนตัว แต่ฉันได้ยินมาว่ามีบางแห่งที่ครอบคลุมรหัสติดตามและจำนวนการทดสอบ ดังนั้นหากการรวบรวมตัวชี้วัดเป็นผลข้างเคียงของ TDD ดังนั้นฉันจะเห็นว่าเป็นค่าลบเช่นกัน ฉันจะลบโค้ด 1,000 บรรทัดอย่างกระตือรือร้นและหากการทดสอบนั้นล้าการทดสอบ 20 รายการและลดการครอบคลุมโค้ดของฉัน% เอาล่ะ

ฉันจะออกไปข้างนอกที่นี่และประกาศด้วยความซื่อสัตย์อย่างโหดร้ายว่าแท้จริงแล้วมันเป็นการเสียเวลาในพิธีกรรม (ในสถานการณ์ส่วนใหญ่)

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

1. ไม่ใช่เอกสารที่ดีไปกว่าเอกสารจริง
2. ไม่ได้จับข้อบกพร่องหรือถดถอย
3. ไม่ได้จริงๆทำให้การออกแบบของฉันดีกว่าพวกเขาจบลงได้ถ้าผมใช้บางฟังก์ชั่นการเขียนโปรแกรมและcomposabilityแนวคิด
4. เป็นเวลาที่อาจใช้เวลาดีกว่าในการตรวจสอบโค้ดหรือขัดเอกสารและข้อมูลจำเพาะ
5. ให้ความปลอดภัยแก่ผู้จัดการโดยผิดเมื่อพวกเขาเห็นรายการไอคอนสีเขียวหลายร้อยรายการ
6. ปรับปรุงประสิทธิภาพในการใช้งานอัลกอริทึมด้วยการแมปอินพุต - เอาท์พุตที่ จำกัด
7. งุ่มง่ามในการที่คุณอาจรู้ว่าสิ่งที่คุณทำเป็นผลมาจาก TDD แต่คุณไม่ได้รับความเข้าใจว่าทำไมมันถึงทำงานได้ดีทำไมการออกแบบของคุณออกมาในแบบที่พวกเขาทำ

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

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

ในทางวัฒนธรรม TDD แสดงอาการของการเป็นนักปฏิบัติพิธีกรรม มันขี่ผิด; ส่งเสริมขั้นตอนการทำความเข้าใจ มันมีหลักคำสอนและคำขวัญมากมาย ("ปลอมมันจนกว่าคุณจะทำมัน" มันค่อนข้างน่ากลัวจริงๆถ้าคุณมองอย่างเป็นกลาง) คำจำกัดความของวิกิพีเดียในคำว่า "พิธีกรรม" นั้นแท้จริงแล้วค่อนข้างชัดเจน:

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

ในการเพิ่มข้อกังวลอื่น ๆ กับ TDD ที่ฉันสังเกตเห็นคือ:

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

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

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

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

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

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

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

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

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

ในฐานะแฟนตัวยงของ TDD บางครั้งฉันเห็นข้อเสียเหล่านี้

• สิ่งล่อใจที่จะเขียนการทดสอบมากเกินไปเพราะครอบคลุมเกือบ 100% ของรหัส ในความคิดของฉันไม่จำเป็นต้องเขียนแบบทดสอบ
  • สำหรับ getters / setters แบบง่าย
  • สำหรับทุกกรณีเมื่อมีข้อยกเว้นถูกโยน
  • ที่ตรวจสอบการทำงานเดียวกันผ่านเลเยอร์ต่างๆ (ตัวอย่าง: หากคุณมี unittest ในการตรวจสอบการตรวจสอบความถูกต้องของอินพุตสำหรับพารามิเตอร์ทุกตัวคุณไม่จำเป็นต้องทำการทดสอบเหล่านี้ซ้ำผ่านการทดสอบการรวมระบบด้วย)

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

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

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

บางทีสักวันหนึ่งจะเปลี่ยนความคิดของฉัน แต่ในบรรดาวิธีปฏิบัติ XP ความคิดในการปรับโครงสร้างใหม่อย่างไร้ความปราณีและการพัฒนารหัสในรูปแบบของตัวเองนั้นสำคัญกว่าและนำไปสู่ผลผลิตที่ยิ่งใหญ่ที่สุดสำหรับฉัน cf อ้างจากกระดาษโดย James Newkirk :

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

แนวคิดของความกล้าหาญและการป้อนกลับแบบวนซ้ำซึ่งเขากล่าวถึงในใจของฉันก็เป็นกุญแจสำคัญในการเพิ่มผลผลิต

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

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

zealots TDD

สำหรับฉันพวกเขาเป็นเพียงหนึ่งในสายบ้าของศาสนาที่เคาะประตูของฉันพยายามที่จะพิสูจน์ว่าวิธีการของฉันในการทำสิ่งต่าง ๆ ไม่สามารถแก้ไขได้อย่างไม่สามารถแก้ไขได้และเส้นทางเดียวสู่ความรอดคือ Jesus, Kent Back หรือการทดสอบหน่วย

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

และเปรียบเทียบมัน Solver Peter Norvig sudoku ไม่ได้ทำโดยใช้ TDD แต่ใช้วิศวกรรมแบบเก่า: http://norvig.com/sudoku.html

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

TDD มีประโยชน์บางประการ:

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

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

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

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

สิ่งที่ทำให้ฉันรำคาญเกี่ยวกับ TDD คือความจริงที่ว่ามีกฎหรือแนวทางปฏิบัติมากมายเกี่ยวกับเรื่องนี้ เนื่องจากมันยังค่อนข้างใหม่เราจึงรู้สึกว่าเป็นมือใหม่ที่ TDD ดังนั้นสิ่งที่ทำงานได้ดีสำหรับเราบางคนอาจไม่ได้ผลสำหรับคนอื่น สิ่งที่ฉันต้องการจะพูดคือไม่มีวิธี "ผิดหรือถูก" จริงในการแสดง TDD: มีวิธีที่เหมาะกับฉัน - และทีมของฉันถ้าฉันมี

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

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

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

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

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

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

ฉันควรจะมีการทดสอบที่แข็งแกร่งกว่าซึ่งจับกรณีขอบ QA ที่ค้นพบ แต่เมื่อคุณมีระบบเช่นนี้ซึ่งตั้งอยู่บนระบบฟิสิกส์และเกมเพลย์มากมายและคุณต้องรับมือกับพฤติกรรมเมื่อเวลาผ่านไปมันจะกลายเป็น ฝันร้ายที่จะระบุสิ่งที่เกิดขึ้น

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