ทำไมการพัฒนาขับเคลื่อนทดสอบจึงขาดหายไปจากการทดสอบของ Joel

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

การพัฒนาที่ขับเคลื่อนการทดสอบนั้นไม่เป็นที่ทราบแน่ชัดก่อนที่หนังสือของ Kent Beck ออกมาในปี 2002 สองปีหลังจาก Joel เขียนบทความนั้น คำถามจึงกลายเป็นว่าทำไมโจเอลไม่ปรับปรุงการทดสอบของเขาหรือถ้า TDD เป็นที่รู้จักกันดีในปี 2000 เขาจะรวมมันไว้ในเกณฑ์ของเขาหรือไม่?

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

โจเอลได้กล่าวถึงเรื่องนี้โดยเฉพาะในบางแห่ง

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

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

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

Joel Spolsky ตอบคำถามนี้เองในปี 2552 :

Joel:มีการถกเถียงกันเกี่ยวกับการพัฒนาระบบขับเคลื่อนทดสอบ ... หากคุณมีการทดสอบหน่วยสำหรับทุกสิ่งสิ่งต่าง ๆ ... ผู้คนจำนวนมากเขียนถึงฉันหลังจากอ่านการทดสอบ Joel เพื่อพูดว่า "คุณควรมี 13 นี่คือการทดสอบหน่วยการทดสอบหน่วย 100% ของโค้ดทั้งหมดของคุณ "

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

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

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

ไม่มีใครนอกจากโจเอลสามารถตอบได้อย่างแน่นอน แต่เราสามารถลองด้วยเหตุผล / ข้อสังเกต

ก่อนอื่นการทดสอบไม่ได้ขาดจากการทดสอบของโจเอล

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

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

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