อะไรคือความเกี่ยวข้องของการทดสอบหน่วยในสภาพแวดล้อมแบบ“ ปล่อยก่อนกำหนดบ่อย ๆ ”?

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

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

1. แพลตฟอร์มทั้งหมดได้รับการผสมผสานอย่างดีกับการสร้าง / วางจำหน่ายลูกค้าทำงานโดยไม่มีจุดร้อน

2. ความต้องการฟังก์ชั่นใหม่ยังคงมาและเราจะเพิ่มพวกเขาในขณะที่เราไป

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

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

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

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

อะไรคือวิธีปฏิบัติที่ดีที่สุดในการทดสอบแพลตฟอร์มสำหรับผู้ใหญ่ในสภาพแวดล้อมที่มีการเปิดตัวเร็ว ๆ

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

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

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

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

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

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

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

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

ตามที่แนะนำโดยDoc BrownและThorbjørn Ravn Andersenการออกรุ่นแรก ๆ มักจะได้รับประโยชน์จากสภาพแวดล้อมที่ดีกว่าจากการทดสอบที่ดีและการพัฒนาที่ขับเคลื่อนด้วยหน่วยทดสอบที่ดีกว่ารุ่นที่มีรอบการปล่อยที่ยาวนาน

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