รับลูกบอลกลิ้งบน TDD


10

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

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

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

ฉันจะโน้มน้าวลูกค้าของเราว่าพวกเขาต้องการใช้เงินสำหรับการทดสอบหน่วยและการพัฒนาแบบทดสอบได้อย่างไร มีการศึกษาใดที่แสดง ROI ของการทดสอบหน่วย?


1
มันสายเกินไปสำหรับ TDD; ดู "การทำงานกับรหัสมรดก" โดย Michael Feathers
Steven A. Lowe

ขั้นตอนที่ 1 ค้นหา Stack Overflow สิ่งนี้ถูกถาม และตอบคำถาม ตัวอย่าง: stackoverflow.com/search?q=starting+tdd
S.Lott

คำตอบ:


6

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

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

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


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

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

ชัดเจนสำหรับฉันในฐานะนักพัฒนา แต่ฉันรู้ว่าการจัดการมักจะต้องมีข้อโต้แย้งที่น่าเชื่อถือมาก (เช่นการจ่ายค่าใช้จ่ายให้เหมาะสม)
เบอร์นาร์ด

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

3

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


0

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

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

มีวิธีอื่นและพยายามเข้าร่วมผู้จัดการของคุณในการเข้าร่วมการประชุม Agile ที่เกิดขึ้น มันควรจะคุ้มค่าที่จะเข้าร่วม

หากคุณคิดว่าไม่มีอะไรทำงานให้ย้าย ... เข้าร่วมสถานที่ที่เหมาะกับคุณ ตรงไปตรงมานี่คือสิ่งที่ฉันทำ เมื่อทุกอย่างล้มเหลวฉันก็ย้ายไป;)

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

ขอให้คุณโชคดีและประสบความสำเร็จ!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.