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


140

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

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

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

ดังนั้นฉันเดาว่าสิ่งที่ฉันถามก็คือ

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

(เห็นได้ชัดว่าคำตอบของประเด็นที่สามนั้นขึ้นอยู่กับว่าคุณกำลังพูดคุยกับผู้บริหารหรือนักพัฒนา)


เหตุผลในการรับรางวัล

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

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


11
หน้าที่เชื่อมโยงกับหนังสือของ Michael Feathers ในหัวข้อ: amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/…
Mark Rushakoff

1
@ Mark - ขอบคุณมันอยู่ในลิงค์ที่ฉันให้ไว้ ฉันหวังว่าจะได้คำตอบที่ดีโดยไม่ต้องซื้อหนังสือเล่มอื่น ... แม้ว่าคุณจะไม่มีหนังสือมากเกินไป (เว้นแต่คุณต้องการทำงานให้เสร็จ)
djdd87

1
คุณจำเป็นต้องอ่านหนังสือเล่มนี้จริง ๆ :) มันเป็นหนึ่งในรายการโปรดของฉันและช่วยให้เข้าใจถึงความตึงเครียดระหว่างการปรับโครงสร้างและการทดสอบอัตโนมัติ
manuel aldana

คำตอบ:


177

ฉันได้นำการทดสอบหน่วยไปใช้กับรหัสฐานที่ไม่เคยมีมาก่อน โครงการใหญ่ครั้งสุดท้ายที่ฉันเกี่ยวข้องกับที่ที่ฉันทำสิ่งนี้ผลิตภัณฑ์ได้ทำการผลิตแล้วโดยไม่มีการทดสอบหน่วยเมื่อฉันมาถึงทีม เมื่อฉันออกจาก - 2 ปีต่อมา - เรามีการทดสอบมากกว่า 4,500 ครั้งขึ้นไปให้ผลการครอบคลุมรหัส 33% ในฐานรหัสด้วย LOC การผลิต 230,000+ รายการ (แอปพลิเคชันชนะทางการเงินแบบเรียลไทม์) สิ่งนั้นอาจฟังดูต่ำ แต่ผลลัพธ์ก็คือการปรับปรุงคุณภาพโค้ดและอัตราข้อบกพร่องอย่างมีนัยสำคัญรวมถึงขวัญกำลังใจและผลกำไรที่ดีขึ้น

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

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

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

การเปลี่ยนเป็นหน่วยทดสอบรหัสของคุณเป็นการลงทุนในผู้คนและทักษะเช่นเดียวกับคุณภาพของรหัสฐาน การเข้าใจสิ่งนี้มีความสำคัญมากในแง่ของความคิดและการจัดการความคาดหวัง

ตอนนี้สำหรับความคิดเห็นและคำถามของคุณ:

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

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

คำตอบระดับลึกคือ: มันไม่สำคัญ คุณเริ่มต้นโดยไม่มีการทดสอบ เริ่มเพิ่มการทดสอบและสร้างซ้ำตามที่คุณไป เมื่อระดับทักษะดีขึ้นให้เริ่มเพิ่มแถบสำหรับโค้ดที่เพิ่งเขียนใหม่ทั้งหมดที่เพิ่มในโครงการของคุณ ปรับปรุงอย่างต่อเนื่อง ฯลฯ ...

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

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

ข่าวดีก็คือว่าเมื่อผ่านไปหลายเดือน (และหลายปี) รหัสของคุณจะค่อยๆกลายเป็น "เหมาะสม" และได้รับการทดสอบอย่างดี

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

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

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

ฝึกคนของคุณ

เริ่มต้นที่ไหนสักแห่งและเริ่มเพิ่มการทดสอบในขณะที่คุณดำเนินการจากมุมมองของลูกค้า (ดูด้านล่าง)

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

เวลาบิลด์ควรเป็น FAST เสมอ หากเวลาสร้างของคุณช้าทักษะการทดสอบหน่วยของคุณจะล้าหลัง ค้นหาการทดสอบที่ช้าและปรับปรุง (แยกรหัสการผลิตและการทดสอบแยก) เขียนได้ดีคุณควรจะมีหลายพันหน่วยทดสอบและยังคงสร้างใน 10 นาที (~ 1 - ไม่กี่ ms / ทดสอบเป็นแนวทางที่ดี แต่หยาบมากบางข้อยกเว้นบางอย่างอาจใช้เช่นรหัสโดยใช้การสะท้อน ฯลฯ )

ตรวจสอบและปรับตัว

ฉันจะมั่นใจได้อย่างไรว่าการทดสอบนั้นมีคุณภาพดีและไม่ใช่แค่กรณีของการทดสอบใด ๆ นั้นดีกว่าไม่มีการทดสอบ

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

หากคุณไม่มีประสบการณ์หรือคำพิพากษาดังกล่าวให้ลองทำสัญญากับคนที่ทำเช่นนั้น

ตัวบ่งชี้รองหยาบสองตัวครอบคลุมรหัสทั้งหมดและสร้างความเร็ว

มันคุ้มค่ากับความพยายามในการแก้ปัญหาที่มีอยู่ในการผลิตหรือไม่?

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

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

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

คำตอบส่วนบุคคลของฉันจะเป็น "ใช่แน่นอน" ในกรณีส่วนใหญ่เพราะฉันรู้ดีกว่ามาก แต่ฉันรู้ว่าอาจมีข้อยกเว้น

สิ่งที่จะเป็นประโยชน์มากขึ้น ใช้เวลาสองสามสัปดาห์ในการเพิ่มการทดสอบหรือไม่กี่สัปดาห์ที่จะเพิ่มฟังก์ชั่น?

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

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

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

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

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

หวังว่าจะช่วย


สะท้อนความคิดเช่นเดียวกับฉัน ขณะนี้ฉันกำลังแสดงกระบวนการ / วิธีที่แน่นอนนี้เพื่อแนะนำกรณีทดสอบในแอปพลิเคชัน JAVA ขนาดใหญ่ :)
Darshan Joshi

3
นี่เป็นคำตอบที่ชัดเจนที่สุดในหัวข้อใด ๆ ที่ฉันเคยอ่านใน Stackoverflow ทำได้ดี! หากคุณยังไม่ทำเช่นนั้นฉันอยากให้คุณลองเขียนหนังสือเกี่ยวกับคำตอบของคำถามสุดท้าย
Yermo Lamers

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

2
คำแนะนำการทดสอบหน่วย dudes นี้เป็นคำแนะนำชีวิตทั่วไป อย่างจริงจัง.
Wjdavis5

24
  • มันคุ้มค่ากับความพยายามในการแก้ปัญหาที่มีอยู่ในการผลิตหรือไม่?

ใช่

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

No!

  • สิ่งที่จะเป็นประโยชน์มากขึ้น ใช้เวลาสองสามสัปดาห์ในการเพิ่มการทดสอบหรือไม่กี่สัปดาห์ที่จะเพิ่มฟังก์ชั่น?

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

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

จากนั้นใส่ในการทดสอบสำหรับแต่ละข้อผิดพลาดในปัจจุบันในฐานข้อมูลข้อผิดพลาดของคุณที่ก่อให้เกิดข้อผิดพลาดที่แน่นอนและจะผ่านเมื่อข้อผิดพลาดได้รับการแก้ไข จากนั้นแก้ไขข้อบกพร่องเหล่านั้น! :-)

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


ขอบคุณสำหรับคำตอบที่บรรจง ยืนยันสิ่งที่ฉันรู้สึก จะเห็นคำตอบอื่น ๆ ที่โพสต์ก่อนที่จะลงคะแนนของฉันและยอมรับว่า
djdd87

15

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

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


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

13

ฉันเห็นด้วยกับสิ่งที่คนอื่นพูดมากที่สุด การเพิ่มการทดสอบไปยังรหัสที่มีอยู่มีค่า ฉันจะไม่เห็นด้วยกับจุดนั้น แต่ฉันต้องการเพิ่มหนึ่ง caveat

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

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

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

  • รหัสใหม่ที่คุณเขียนควรอยู่ภายใต้การทดสอบหน่วย
  • รหัสเก่าที่คุณสัมผัส (แก้ไขข้อผิดพลาดส่วนขยาย ฯลฯ ) ควรอยู่ภายใต้การทดสอบหน่วย

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

แก้ไข:

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

นี่เหมือนกับถามว่า "ข้อดีและข้อเสียของการใช้การควบคุมแหล่งที่มาคืออะไร" หรือ "อะไรคือข้อดีข้อเสียของการสัมภาษณ์ผู้คนก่อนจ้างพวกเขา?" หรือ "อะไรคือข้อดีข้อเสียของการหายใจ?"

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


9

เมื่อเราเริ่มเพิ่มการทดสอบมันเป็นรหัสฐานสิบล้านปีที่มีอายุประมาณสิบล้านบรรทัดซึ่งมีตรรกะที่มากเกินไปใน UI และในรหัสการรายงาน

หนึ่งในสิ่งแรกที่เราทำ (หลังจากตั้งค่าเซิร์ฟเวอร์สร้างอย่างต่อเนื่อง) คือการเพิ่มการทดสอบการถดถอย เป็นการทดสอบแบบครบวงจร

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

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

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

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

การทดสอบการถดถอยมีปัญหา: มันช้าและมีเหตุผลมากมายที่ทำให้พวกเขาแตกได้ แต่อย่างน้อยสำหรับเราพวกเขาเพื่อให้คุ้มค่า พวกเขาจับข้อบกพร่องได้นับไม่ถ้วนในช่วงห้าปีที่ผ่านมาและพวกเขาจับพวกมันได้ภายในเวลาไม่กี่ชั่วโมงแทนที่จะรอวงจร QA เรายังคงมีการทดสอบการถดถอยดั้งเดิมเหล่านั้นแผ่กระจายไปทั่วเครื่องสร้างต่อเนื่องเจ็ดแบบที่แตกต่างกัน (แยกต่างหากจากเครื่องที่รันการทดสอบแบบเร็ว) และเรายังเพิ่มพวกมันเป็นครั้งคราวเพราะเรายังมีรหัสมากที่ 6,000 ของเรา + การทดสอบหน่วยไม่ครอบคลุม


8

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

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

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


6

ฉันจะเพิ่มเสียงของฉันและพูดว่าใช่มันมีประโยชน์เสมอ!

มีข้อแตกต่างบางประการที่คุณควรจำไว้: Black-box กับ White-box และ Unit vs functional เนื่องจากคำจำกัดความแตกต่างกันไปนี่คือสิ่งที่ฉันหมายถึงโดยสิ่งเหล่านี้:

  • Black-box = การทดสอบที่เขียนขึ้นโดยไม่มีความรู้พิเศษเกี่ยวกับการใช้งานโดยทั่วไปแล้วจะมีการพูดถึงกรณีขอบเพื่อให้แน่ใจว่าสิ่งต่าง ๆ จะเกิดขึ้นตามที่ผู้ใช้ไร้เดียงสาคาดหวัง
  • White-box = การทดสอบที่เขียนขึ้นด้วยความรู้เกี่ยวกับการใช้งานซึ่งมักจะพยายามฝึกจุดบกพร่องที่รู้จักกันดี
  • การทดสอบหน่วย = การทดสอบของแต่ละหน่วย (ฟังก์ชั่นโมดูลที่แยกกันได้ ฯลฯ ) ตัวอย่างเช่น: ตรวจสอบให้แน่ใจว่าคลาสอาเรย์ของคุณทำงานตามที่คาดไว้และฟังก์ชันการเปรียบเทียบสตริงของคุณจะส่งคืนผลลัพธ์ที่คาดหวังสำหรับอินพุตที่หลากหลาย
  • ฟังก์ชั่นการทดสอบ = การทดสอบของระบบทั้งหมดทั้งหมดในครั้งเดียว การทดสอบเหล่านี้จะออกกำลังกายชิ้นใหญ่ของระบบทั้งหมดในครั้งเดียว ตัวอย่างเช่น: init, เปิดการเชื่อมต่อ, ทำบางสิ่งในโลกแห่งความเป็นจริง, ปิด, ยุติ ฉันชอบที่จะวาดความแตกต่างระหว่างการทดสอบเหล่านี้และหน่วยการเรียนรู้เพราะพวกเขามีวัตถุประสงค์ที่แตกต่างกัน

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

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

เช่นเดียวกับคนอื่น ๆ ฉันจะเตือนคุณถึงสองสิ่งที่สำคัญที่สุดเกี่ยวกับ TDD:

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

4

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

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

คำตอบสำหรับคำถามที่สามของฉันเหมือนกับคำถามแรกนั้นขึ้นอยู่กับบริบทของโครงการของคุณ

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


4

คุณไม่ได้พูดถึงภาษาที่ใช้งาน แต่ถ้าใน Java คุณสามารถลองใช้วิธีนี้:

  1. ในการแยกการสร้างแผนภูมิต้นกำเนิดที่แยกต่างหากหรือการทดสอบ 'ควัน' โดยใช้เครื่องมือในการสร้างซึ่งจะทำให้คุณได้รับความครอบคลุมมากถึง 80% การทดสอบเหล่านี้ดำเนินการเส้นทางตรรกะของรหัสทั้งหมดและตรวจสอบจากจุดนั้นว่ารหัสยังคงทำในสิ่งที่มันทำในปัจจุบัน (แม้ว่าจะมีข้อผิดพลาด) สิ่งนี้จะช่วยให้คุณปลอดภัยจากการเปลี่ยนแปลงพฤติกรรมโดยไม่ตั้งใจเมื่อทำการปรับโครงสร้างที่จำเป็นเพื่อให้โค้ดทดสอบได้ง่ายด้วยมือ

    • คำแนะนำผลิตภัณฑ์ - ฉันเคยใช้ผลิตภัณฑ์ Junit Factory จากเว็บฟรี แต่น่าเสียดายที่ตอนนี้ปิดแล้ว อย่างไรก็ตามผลิตภัณฑ์มีอายุการใช้งานใน AgitarOne JUnit Generator ที่ได้รับใบอนุญาตในเชิงพาณิชย์ที่http://www.agitar.com/solutions/products/automated_junit_generation.html
  2. สำหรับแต่ละข้อบกพร่องที่คุณแก้ไขหรือฟีเจอร์ที่คุณเพิ่มนับจากนี้ไปใช้วิธีการ TDD เพื่อให้แน่ใจว่ารหัสใหม่ได้รับการออกแบบให้สามารถทดสอบได้และวางการทดสอบเหล่านี้ในแผนภูมิแหล่งทดสอบปกติ

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

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

  5. เมื่อแก้ไขข้อบกพร่องให้เขียนการทดสอบหน่วยที่ล้มเหลวที่ทำให้เกิดข้อบกพร่องก่อน


3

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

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

มันคุ้มค่ากับความพยายามในการแก้ปัญหาที่มีอยู่ในการผลิตหรือไม่?

ใช่. คุณจะเห็นผลของบั๊กที่เกิดขึ้นและการบำรุงรักษาง่ายขึ้น

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

ฉันอยากจะแนะนำให้เริ่มถ้าจากนี้

สิ่งที่จะเป็นประโยชน์มากขึ้น ใช้เวลาสองสามสัปดาห์ในการเพิ่มการทดสอบหรือไม่กี่สัปดาห์ที่จะเพิ่มฟังก์ชั่น?

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


3

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

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


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

2

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

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


2

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

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

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


2

ปรับปรุง

6 ปีหลังจากคำตอบเดิมฉันใช้เวลาต่างกันเล็กน้อย

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

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

คำตอบก่อนหน้า

ฉันจะยกคิ้วขึ้นสักครู่ที่นี่ :)

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

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

ทำไม?

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

  2. เวลาทดสอบหน่วยต้นทุน! ตอนนี้ฉันมาจากไหนนั่นเป็นสิ่งมีค่า - และโดยทั่วไปแล้วธุรกิจจะเลือกฟังก์ชั่นที่ดีกว่าผ่านชุดทดสอบที่สมบูรณ์

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

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

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

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


และฉันขอให้คุณอ่าน - joelonsoftware.com/items/2009/01/31.html
Roopesh Shenoy

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

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

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

1

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

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

OTOH มันไม่คุ้มค่าแค่นั่งเขียนข้อสอบรอบ ๆ รหัสที่ผู้คนมีความสุขกับมัน - โดยเฉพาะอย่างยิ่งถ้าไม่มีใครจะแก้ไขมัน มันไม่ได้เพิ่มคุณค่า (ยกเว้นอาจจะเข้าใจพฤติกรรมของระบบ)

โชคดี!


1

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


1

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

จากนั้นฉันจะทำการพัฒนาข้อบกพร่องสำหรับข้อบกพร่องที่ค้นพบใหม่การเขียนการทดสอบหน่วยเพื่อสร้างปัญหาและทำงานกับข้อบกพร่องจนกระทั่งการทดสอบผ่าน

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

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


1

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

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

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

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

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


1

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


1

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

1) วัดAfferent Coupling (CA)ของรหัสของคุณ(คลาสอื่นที่คลาสอื่นใช้ซึ่งหมายถึงการทำลายคลาสนั้นจะทำให้เกิดความเสียหายอย่างกว้างขวาง)

2) วัดความซับซ้อน Cyclomatic (CC)ของรหัสของคุณ(ความซับซ้อนที่สูงขึ้น = การเปลี่ยนแปลงที่สูงขึ้นของการทำลาย)

คุณต้องระบุคลาสที่มี CA และ CC สูงเช่นมีฟังก์ชั่นf (CA, CC)และคลาสที่มีความแตกต่างน้อยที่สุดระหว่างสองเมทริกควรได้รับความสำคัญสูงสุดสำหรับการครอบคลุมการทดสอบ

ทำไม? เนื่องจาก CA สูง แต่คลาส CC ต่ำมากมีความสำคัญมาก แต่ไม่น่าจะแตก ในทางตรงกันข้าม CA ต่ำ แต่ CC สูงมีแนวโน้มที่จะทำลาย แต่จะทำให้เกิดความเสียหายน้อยลง ดังนั้นคุณต้องการความสมดุล


0

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


-2

ใช่. ไม่การเพิ่มการทดสอบ

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

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