เพื่อนร่วมงานไม่เต็มใจที่จะใช้การทดสอบหน่วย“ เพราะมีรหัสมากกว่า”

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

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

ดังนั้นวิธีที่ดีที่สุดสำหรับฉันคืออะไร

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

• การรับรู้ของเธอ

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

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

ในการเตรียมตัวคุณควรตรวจสอบ P.SE หรือ Google สำหรับการจัดการทุกสิ่งหรือนักพัฒนาที่กังวลเกี่ยวกับการทดสอบหน่วยและรวบรวมคำตอบที่คุณจะใช้ระหว่างการหารือกับเพื่อนร่วมงานของคุณ

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

เขียนบททดสอบ (อย่าบอกเธอ)

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

ครอบคลุม ...

การทำงานอัตโนมัติด้วยตนเองเป็นอย่างอื่นควรดึงดูดโปรแกรมเมอร์คนใดก็ได้

ดังนั้นเธอจึงไม่ได้ "เขียนโค้ดเพิ่มเติม" เธอทำน้อยลงด้วยตนเอง

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

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

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

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

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

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

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

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

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

ในการเล่นผู้สนับสนุนปีศาจ: เธอมีประเด็น ฉันมักจะใส่มันเป็น:

การทดสอบอัตโนมัติแก้ปัญหาของรหัสมากด้วยรหัสมากขึ้น

เหตุผล:

• การศึกษาเกี่ยวกับความสัมพันธ์ของอัตราความผิดพลาดและตัวชี้วัด OOผลหัวข้อ: "หลังจากที่ควบคุมขนาด [การเรียน] ไม่มีตัวชี้วัดที่เราศึกษามีความสัมพันธ์กับความผิด proneness อีกต่อไป" (การศึกษากล่าวถึงขนาดของชั้นเรียนผลกระทบนี้ขยายขนาดของฐานรหัสหรือไม่น่าจะเป็นในความคิดของฉัน)
• สังเกตุโครงการขนาดใหญ่มักจะก้าวไปข้างหน้าอย่างช้าๆ "5K บรรทัดข้ามคืนในโครงการใหม่" กับ "10 บรรทัด / วันสำหรับโครงการขนาดใหญ่" นั่นแสดงว่า "การต่อต้าน" เพื่อเปลี่ยนการเพิ่มขึ้นตามขนาดของรหัสฐานหรือไม่?
• เรามักจะประกาศว่า "ไม่มีภาษาที่ดีที่สุดมันขึ้นอยู่กับปัญหา" ข้อกำหนดสำคัญประการหนึ่งคือการสร้างแบบจำลองเอนทิตีของปัญหาและการดำเนินงานได้อย่างง่ายดายในภาษาที่เลือก ไม่แนะนำให้เลือกภาษาที่แสดงว่าปัญหาของคุณนั้นซับซ้อนกว่านี้และยิ่งไม่เกี่ยวข้องกับขนาดฐานสุดท้ายของรหัสอีกหรือไม่

ตอนนี้มีข้อโต้แย้งเล็กน้อยที่จะยิงได้อย่างง่ายดาย ให้ฉันอยู่กับสิ่งที่ฉันคิดได้:

• ขนาดกับความเรียบง่าย: แน่นอนว่ามันเป็นไปได้ที่จะทำให้โค้ดสั้นลงและแย่ลง อย่างไรก็ตามนั่นเป็นเพียงปัญหาเมื่อเปรียบเทียบฐานโค้ดกับอัตราส่วนความกะทัดรัด - ความเรียบง่ายที่แตกต่างกันสำหรับการสนทนาเราสามารถสันนิษฐานได้ว่าเราสามารถควบคุมปัจจัยนี้ได้

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

TL: DR:ฉันไม่เถียงการทดสอบหน่วยไม่ดี ฉันถามว่า: มีจุดคุ้มทุนหรือไม่ที่การทดสอบความเจ็บปวดมีความสัมพันธ์กับจำนวนรหัสหรือไม่

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

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

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

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

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

เธอเป็นเจ้านายหรือไม่

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

เธอไม่ใช่เจ้านายใช่ไหม

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

กรณีเอกสารที่ TDD สามารถประหยัดเวลา & $$ MONEY $$

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

สิ่งนี้ทำให้ฉันอยู่ในตำแหน่งของการแก้ไขบางสิ่งบางอย่าง

ทำไม?

พวกเขาสร้างปัญหา พวกเขาควรแก้มัน

ผู้จัดการคนใดยอมให้สิ่งนี้เกิดขึ้น? ทำไมรหัสรถบักกี้ของคนอื่นถึงเป็นปัญหาของคุณ?

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

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

เธอค่อนข้างถูกต้องการทดสอบหน่วยเป็น "รหัสเพิ่มเติม"

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

ท้าทายเธอใน:

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

การพูดเป็นรหัสที่ใช้งานจริงในปัจจุบันตามด้วยการทดสอบหน่วยแทนที่จะเป็น TDD ซึ่งดูเหมือนจะไม่เหมาะกับสถานที่ปัจจุบันของฉัน (ฉันได้ทำ TDD ในบางโครงการ แต่เห็นว่าเป็นเครื่องมืออื่นใน กระเป๋า ol 'ไม่ใช่กระสุนเงิน) ...

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

แสดงให้เธอเห็นว่าการทดสอบหน่วยช่วยด้วยการสร้างบททดสอบด้วยตัวเอง

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

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

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