จุดประสงค์ของการทดสอบหน่วยบนเซิร์ฟเวอร์ CI คืออะไร

ทำไมคุณถึงเรียกใช้การทดสอบหน่วยบนเซิร์ฟเวอร์ CI

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

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

หรือไม่. อาจมีสาเหตุหลายประการที่ทำให้สิ่งนี้เกิดขึ้น:

• นักพัฒนาไม่มีวินัยในการทำเช่นนั้น
• พวกเขาลืมไปแล้ว
• พวกเขาไม่ได้กระทำทุกอย่างและผลักดันชุดการกระทำที่ไม่สมบูรณ์ (ขอบคุณMatthieu M.
• พวกเขาทำการทดสอบบางอย่างเท่านั้น แต่ไม่ใช่ทั้งชุด (ขอบคุณnhgrif )
• พวกเขาทดสอบในสาขาของพวกเขาก่อนที่จะรวม (ขอบคุณnhgrif * 2)

แต่จุดที่แท้จริงคือการรันการทดสอบบนเครื่องที่ไม่ใช่เครื่องผู้พัฒนา หนึ่งที่กำหนดค่าแตกต่างกัน

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

เหตุผลที่ดีอื่น ๆ สำหรับ CI สร้างเพื่อใช้ทดสอบ:

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

ในฐานะนักพัฒนาซอฟต์แวร์ที่ไม่ได้ทำการทดสอบการรวมและหน่วยทั้งหมดก่อนที่จะทำการควบคุมแหล่งข้อมูลฉันจะเสนอการป้องกันของฉันที่นี่

ฉันจะต้องสร้างทดสอบและตรวจสอบว่าแอปพลิเคชันทำงานอย่างถูกต้องใน:

• Microsoft Windows XP และ Vista พร้อมคอมไพเลอร์ Visual Studio 2008
• Microsoft Windows 7 ที่มีคอมไพเลอร์ Visual Studio 2010
  • โอ้และ MSI สร้างขึ้นสำหรับแต่ละสิ่ง
• RHEL 5 และ 6 ที่มี 4.1 และ 4.4 ตามลำดับ (CentOS ในทำนองเดียวกัน)
  • 7 เร็ว ๆ นี้ Woop-de-Woop
• Fedora Workstation กับ GCC สำหรับสามรุ่นล่าสุด
• Debian (และอนุพันธ์เช่น Ubuntu) สำหรับสามเวอร์ชันล่าสุด
• Mac OSX ในสามเวอร์ชันล่าสุด
  • และแพคเกจ (รอบต่อนาที, dmg ฯลฯ )

เพิ่มใน Fortran (ทั้งคอมไพเลอร์ของ Intel และ GNU), Python (และเป็นเวอร์ชันต่าง ๆ ขึ้นอยู่กับระบบปฏิบัติการ) และส่วนประกอบสคริปต์ bash / bat และดีฉันคิดว่าคุณสามารถเห็นสิ่งที่หมุนวน

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

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

นอกเหนือจากคำตอบ Oded ที่ยอดเยี่ยม:

• คุณทดสอบโค้ดจากพื้นที่เก็บข้อมูล มันอาจทำงานกับเครื่องของคุณด้วยไฟล์ของคุณ ... ที่คุณลืมที่จะกระทำ มันอาจขึ้นอยู่กับตารางใหม่ที่ไม่มีสคริปต์การสร้าง (ใน liquibase เช่น) ข้อมูลการกำหนดค่าบางอย่างหรือไฟล์คุณสมบัติ
• คุณหลีกเลี่ยงปัญหาการรวมรหัส นักพัฒนาซอฟต์แวร์หนึ่งคนดาวน์โหลดเวอร์ชันล่าสุดสร้างหน่วยทดสอบและบูรณาการเพิ่มรหัสผ่านการทดสอบทั้งหมดในเครื่องของเขา ผู้พัฒนารายอื่นเพิ่งทำแบบเดียวกัน การเปลี่ยนแปลงทั้งสองอย่างถูกต้องด้วยตัวเอง แต่เมื่อรวมแล้วทำให้เกิดข้อผิดพลาด นี่อาจเป็นการรวมที่เก็บข้อมูลหรือเพียงแค่ตรวจไม่พบว่าเป็นความขัดแย้ง เช่น Dev 1 ลบไฟล์ที่ไม่ได้ใช้เลย รหัส Dev 2 กับไฟล์นี้และการทดสอบโดยไม่มีการเปลี่ยนแปลง Dev 1
• คุณพัฒนาสคริปต์เพื่อปรับใช้โดยอัตโนมัติจากที่เก็บ การมีอาคารสากลและการปรับใช้สคริปต์สามารถแก้ไขปัญหาได้มากมาย นักพัฒนาบางคนอาจเพิ่มตัวเลือก lib หรือการรวบรวมที่ทุกคนไม่ได้แชร์ ไม่เพียง แต่ช่วยคุณประหยัดเวลา แต่ที่สำคัญกว่านั้นยังทำให้การปรับใช้ปลอดภัยและคาดการณ์ได้ นอกจากนี้คุณสามารถกลับไปที่ที่เก็บของคุณเป็นรุ่น 2.3.1 และปรับใช้เวอร์ชันนี้ด้วยสคริปต์ที่ทำงานกับเวอร์ชันนี้ มันมีวัตถุฐานข้อมูลเช่นมุมมองขั้นตอนการจัดเก็บมุมมองและทริกเกอร์ที่ควรเป็นรุ่น (หรือคุณจะไม่สามารถกลับไปใช้เวอร์ชันที่ใช้การได้)
• การทดสอบอื่น ๆ : เช่นเดียวกับการรวมประสิทธิภาพและสิ้นสุดการทดสอบ สิ่งนี้อาจช้าและอาจรวมถึงเครื่องมือทดสอบเช่น Selenium คุณอาจต้องการชุดข้อมูลที่สมบูรณ์พร้อมฐานข้อมูลจริงแทนที่จะเป็นวัตถุจำลองหรือ HSQL

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

คุณคิดว่าไม่ใช่คุณ - แต่นักพัฒนาเป็นมนุษย์และบางครั้งพวกเขาก็ลืม

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

การทดสอบของคุณอาจขึ้นอยู่กับทรัพยากรในพื้นที่ (ไม่ จำกัด ) สิ่งที่การทดสอบหน่วยท้องถิ่นของคุณจะไม่ได้รับ

หากคุณคิดว่าสิ่งที่กล่าวมาข้างต้นมีความเพ้อฝันมีระดับที่สูงกว่า CI (อย่างน้อยใน TFS) เรียกว่าGatedโดยที่การสร้างที่มีการทดสอบที่ล้มเหลวจะถูกจัดวางและไม่ได้มุ่งมั่นที่จะสร้างฐานรหัส

เมื่อถึงเวลาที่บางสิ่งมุ่งมั่นที่จะเป็นผู้เชี่ยวชาญ

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

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

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

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

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

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

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

สมมติว่า (ตรงกันข้ามกับคำตอบอื่น ๆ ) ที่นักพัฒนาค่อนข้างมีระเบียบวินัยและทำการทดสอบหน่วยก่อนที่จะกระทำอาจมีหลายสาเหตุ:

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

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

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

นอกจากนี้นักพัฒนาซอฟต์แวร์บางคนไม่ได้เรียกใช้การทดสอบหน่วยทั้งหมดในขณะที่นักพัฒนาซอฟต์แวร์ส่วนใหญ่ทำได้

ลองถามคำถามที่เทียบเท่ากัน

ทำไมคุณต้องสร้างรหัสบนเซิร์ฟเวอร์ CI

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

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

หากรหัสไม่เคยขาดหายไปทำไมเราถึงใช้ CI ในการส่งมอบงานสร้างสำหรับการทดสอบงานสร้างรายต่อคืนจะดีพอ