การทดสอบการรวมเข้าด้วยกันควรรวมอยู่ในการรวมอย่างต่อเนื่อง (CI) หรือไม่

สมมติว่าเรากำลังพัฒนาเว็บแอปพลิเคชันและฮัดสันทำงานทั่วไปเช่นคอมไพล์การทดสอบหน่วยและการวิเคราะห์โค้ดแบบคงที่

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

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

คุณคิดว่าควรรวมการทดสอบการรวมเข้ากับการรวมเข้าด้วยกันอย่างต่อเนื่อง (CI) หรือไม่ เป็นด้วยตนเองได้ไหม หรือลดความซับซ้อนของการทดสอบการรวม?

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

คุณคิดว่าควรรวมการทดสอบการรวมเข้ากับการรวมเข้าด้วยกันอย่างต่อเนื่อง (CI) หรือไม่

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

แต่เนื่องจากการทดสอบการรวมอาจใช้เวลานานในการดำเนินการคุณควร จำกัด ความถี่ในการเรียกใช้ พวกเขาสามารถดำเนินการในช่วงกลางคืนเมื่อเซิร์ฟเวอร์ CI ว่าง

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

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

1. คอมมิชชัน build
2. การทดสอบอย่างละเอียด
3. การใช้งาน

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

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

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

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

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

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