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

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

ข้อดีของ TDD นั้นคุ้มค่ากับการพัฒนาเป็นพิเศษสำหรับทีมเล็ก ๆ ที่มีตารางงานที่แน่นมากหรือไม่?

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

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

ยิ่งทีมของคุณเล็กลงเท่าไหร่คุณก็จะได้ประโยชน์จาก TDD มากขึ้นทันที ฉันเห็นการจ่ายเงินนี้ในขนาดทีมตั้งแต่ 6 ถึง 3

เวลาพัฒนาพิเศษที่คุณกำลังพูดถึงอาจจะเป็นภาพลวงตา

สิ่งที่ทำให้ TDD แตกต่างจากการทดสอบหน่วยมาตรฐานคือมันไม่ได้ใช้เพื่อทำการทดสอบ

TDD is a new way of developing software. มันเป็นหนึ่งในวิธีที่ดีที่สุดที่ฉันรู้

ดังนั้นจึงไม่เกี่ยวข้องกับขนาดของโครงการของคุณ คุณจะดึงประโยชน์จากบรรทัดแรกของรหัส

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

ความเข้าใจผิดที่พบบ่อยให้ฉันตะโกนออกมา:

การทดสอบใน TDD นั้นเป็นคุณสมบัติ

EOM

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

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

มีคำถามสองสามข้อที่คุณต้องได้รับคำตอบสำหรับ:

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

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

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

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

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

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

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

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

Bottom line - การพัฒนาช้าลง แต่มีข้อบกพร่องเล็กน้อยจึงใช้เวลาในการแก้ไขข้อบกพร่องน้อยลง

ที่นี่ฉันคิดว่าการพัฒนาพฤติกรรมขับเคลื่อนได้ผลทันที แต่ฉันไม่แน่ใจว่าการพัฒนาขับเคลื่อนทดสอบ

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

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

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

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

TL; DR:การพัฒนาพฤติกรรมขับเคลื่อนอาจแสดงการปรับปรุงอย่างรวดเร็วเนื่องจากเป็น "ลูกค้า" ที่มุ่งเน้น สำหรับผมแล้วการพัฒนาแบบทดสอบขับเคลื่อนนั้นเกี่ยวกับการทดสอบภายในของ codebase ที่ "ไม่มีใคร" ใส่ใจและให้ประโยชน์ทางธุรกิจที่ชัดเจนน้อยลง (การพัฒนาพฤติกรรมขับเคลื่อนได้ทันทีในหน้าของคุณเปลี่ยนแปลง: วิศวกรก็มีเวลามากขึ้นกับ "ลูกค้า" หรือนักวิเคราะห์ธุรกิจพยายามที่จะได้รับสิทธินี้ - ซึ่งควรจะเห็นว่าเป็นสิ่งที่ดี "โอ้ พวกเขากำลังประชุมเกี่ยวกับ Feature X ซึ่งหมายความว่ามีความคืบหน้าอยู่ข้างหน้า! ")