TDD เทียบกับการทดสอบหน่วย [ปิด]

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

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

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

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

แก้ไข

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

ติดตาม

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

หากทีมกำลังดิ้นรนในการนำ TDD ไปใช้ แต่พวกเขาไม่ได้สร้าง Unit Tests ใด ๆ มาก่อน ... ให้เริ่มด้วยการสร้าง Unit Tests หลังจากเขียนโค้ดแล้ว แม้แต่การทดสอบหน่วยที่เขียนหลังรหัสก็ยังดีกว่าไม่มีการทดสอบหน่วยเลย!

เมื่อมีความเชี่ยวชาญในการทดสอบหน่วย (และทุกสิ่งที่มาพร้อมกับมัน) คุณสามารถดำเนินการเพื่อให้พวกเขาสร้างการทดสอบก่อน ... และรหัสที่สอง

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

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

ในความเห็นที่ต่ำต้อยของฉันดีกว่าที่จะครอบคลุมการทดสอบ 50% ด้วย "โค้ดก่อนทดสอบหลัง" และไลบรารีที่เสร็จสมบูรณ์ 100% ครอบคลุมการทดสอบมากกว่า 100% และห้องสมุดที่เสร็จสมบูรณ์ 50% พร้อม TDD หลังจากนั้นไม่นานนักพัฒนาคนอื่น ๆ ของคุณหวังว่าจะพบว่ามันสนุกและให้ความรู้ในการเขียนแบบทดสอบสำหรับpublicโค้ดทั้งหมดที่พวกเขาเขียนดังนั้น TDD จะแอบเข้าไปในขั้นตอนการพัฒนาของพวกเขา

ฉันเพิ่งอ่านสิ่งนี้ในปฏิทิน: "ทุกกฎที่ดำเนินการอย่างถึงที่สุดกลายเป็นเรื่องไร้สาระหรือแม้กระทั่งอันตราย" ดังนั้นข้อเสนอแนะของฉันคือไม่ต้องนับถือศาสนาเกี่ยวกับเรื่องนี้ สมาชิกทุกคนในทีมของคุณต้องหาจุดสมดุลระหว่างสิ่งที่พวกเขารู้สึกว่า "ถูกต้อง" ในการทดสอบ ด้วยวิธีนี้สมาชิกทุกคนในทีมของคุณจะมีประสิทธิผลมากที่สุด (แทนที่จะพูดโดยคิดว่า "ทำไมฉันต้องเขียน sti **** test นี้ ??")

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

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

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

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

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

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

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

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

นี่คือสิ่งที่ทีมของคุณจะต้องประสบความสำเร็จก่อนที่พวกเขาจะเริ่มเชื่อฉันจะคุยโวเกี่ยวกับความศักดิ์สิทธิ์ของหน่วยงานของฉันสำหรับทุกคนที่สนใจ:

ประมาณ 5 ปีที่แล้วฉันค้นพบ nUnit เมื่อทำงานในโครงการ เราทำ V1.0 เกือบเสร็จแล้วและฉันได้สร้างการทดสอบสองสามครั้งเพื่อทดลองใช้เครื่องมือใหม่นี้ เรามีจุดบกพร่องมากมาย (ชัด ๆ !) เพราะเราเป็นทีมใหม่ในเส้นตายที่รัดกุมความคาดหวังสูง (ฟังดูคุ้น ๆ มั้ย?) ฯลฯ อย่างไรก็ตามเราได้ 1.0 ในและเริ่มใน 1.1 เราปรับโครงสร้างทีมใหม่เล็กน้อยและฉันได้รับ 2 devs ที่มอบหมายให้ฉัน ฉันทำการสาธิต 1 ชั่วโมงสำหรับพวกเขาและบอกพวกเขาว่าทุกสิ่งที่เราเขียนต้องมีกรณีทดสอบด้วย เราวิ่ง "ตามหลัง" ทีมที่เหลืออย่างต่อเนื่องในช่วง 1.1 dev cycle เพราะเราเขียนโค้ดมากขึ้นการทดสอบหน่วย เราลงเอยด้วยการทำงานมากขึ้น แต่นี่คือผลตอบแทน - ในที่สุดเมื่อเราได้ทำการทดสอบเราพบว่ามีจุดบกพร่อง 0 จุดในโค้ดของเรา เราช่วยทุกคนในการแก้ไขข้อบกพร่องและแก้ไขข้อบกพร่องของพวกเขา ในการชันสูตรพลิกศพเมื่อจำนวนข้อผิดพลาดปรากฏขึ้น

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

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

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

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

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

ถ้าคุณไม่เขียนการทดสอบก่อนไม่ใช่ "Test Driven" ก็เป็นเพียงการทดสอบ มันมีประโยชน์ในตัวมันเองและถ้าคุณมีฐานรหัสแล้วการเพิ่มการทดสอบมันก็มีประโยชน์อย่างแน่นอนแม้ว่าจะไม่ใช่ TDD แต่เป็นเพียงการทดสอบ

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

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

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

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

นอกเหนือจากBDDก็อาจเป็นที่สนใจเช่นกัน

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

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

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

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

• มีการรายงานข้อผิดพลาด
• สร้างคลาสทดสอบ JUnit หากจำเป็น
• เพิ่มการทดสอบที่ทำให้เกิดข้อบกพร่อง
• แก้ไขรหัสของคุณ
• เรียกใช้การทดสอบเพื่อแสดงรหัสปัจจุบันไม่ให้เกิดข้อผิดพลาด

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

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

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

วิธีนี้ได้ผลหลายครั้งสำหรับฉันในอดีต

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

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

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

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

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

นี่เป็นการเปลี่ยนแปลงทางสังคม / วัฒนธรรมมากพอ ๆ กับการเปลี่ยนแปลงทางเทคนิค