How Guru’s Engineers Use Cypress for Better Burn Testing
ต้องการวิธีที่ดีกว่าในการจัดการการทดสอบการเผาไหม้? วิศวกรด้านหน้าของเราสองคนได้ค้นพบวิธีการใช้ Cypress เพื่อปรับปรุงวิธีการของพวกเขาในการจัดการการควบคุมคุณภาพ
เรามุ่งมั่นในการแชร์ความรู้ที่ Guru และเมื่อเราค้นพบสิ่งใหม่ที่มีประโยชน์เราต้องการให้โลกรู้! ทีมวิศวกรรมของเราใช้ Cypress ในกระบวนการทดสอบและ QA ของพวกเขา พวกเขาได้ค้นพบวิธีใหม่ในการช่วยให้การทดสอบการเผาไหม้ดียิ่งขึ้นและพวกเขาต้องการแบ่งปันกระบวนการใหม่และที่พัฒนาขึ้นของพวกเขากับวิศวกรและผู้ทดสอบคนอื่น
ในปีที่ผ่านมาเราได้มุ่งเน้นการเพิ่มครอบคลุมการทดสอบของเรา - โดยเฉพาะการทดสอบแบบ end-to-end ที่รับประกันว่าแต่ละส่วนของการทำงานของผลิตภัณฑ์ของเราทำงานอย่างถูกต้องเมื่อเราทำการปรับปรุงโค้ด สำหรับประเภทการทดสอบนี้เราจะใช้เครื่องมือที่ชื่อว่า Cypress ซึ่งเลียนแบบพฤติกรรมของผู้ใช้ด้วยแอพเว็บและส่วนขยายของ Google Chrome ของเรา ชุดการทดสอบนี้จะทำงานในทุกคำขอที่ดึงเพื่อให้แน่ใจว่าโค้ดใหม่ไม่ได้ทำลายสิ่งต่าง ๆ ใน UI ของเรา เรายังต้องการบล็อกการปล่อยไม่ให้เกิดขึ้นหากชุด Cypress ของเราล้มเหลวในสาขาการผลิตของเรา
สิ่งที่เรามองหาในการทดสอบแบบดั้งเดิม
ปัญหาหนึ่งที่เราต้องจัดการคือการเห็นการทดสอบบางรายการล้มเหลวแต่ไม่ใช่ในเหตุผลที่เกี่ยวข้องกับ UI หรือโค้ด แล้ว Cypress ช่วยเราในกรณีเหล่านี้ได้อย่างไร? เรามี Cypress ทำหน้าที่เป็นผู้ใช้ซึ่งพฤติกรรมของเราสามารถกำหนดได้ มีตัวแปรหลายตัวที่อาจทำให้ Cypress บอกเราว่ามีความล้มเหลวแต่จากมุมมองของผู้ใช้ดูเหมือนจะไม่มีอะไรผิดปกติ
ตัวอย่างเช่น อาจมีการทดสอบที่บอกว่า "ไปที่ส่วนนี้ของแอพเว็บ > เพิ่มการ์ด Guru ใหม่ > คาดว่าจะเห็นสถานะหลังการสร้าง" หากสถานะการโหลดของการสร้างการ์ดช้ากว่าที่มันควรจะเป็นและ Cypress เริ่มมองหาสถานะหลังสร้างก่อนที่มันจะอยู่ที่นั่นการทดสอบนี้อาจล้มเหลว (ส่วนมากการทดสอบนี้จะผ่าน) ถ้ามันทดสอบผ่านครั้งเดียวในคำขอที่ดึงเราอาจรวมโค้ดที่อาจมีปัญหาได้ แต่เราไม่รู้ว่ามันจะเป็นอย่างไร; การทดสอบที่ผ่านเป็นการรับประกันว่าโค้ดถูกต้องไม่ได้
ประเภทสถานการณ์เช่นนี้ทำให้ความน่าเชื่อถือของครอบคลุมการทดสอบของเราลดลง ดังนั้นเมื่อมีการล้มเหลวของการทดสอบเกิดขึ้นในสายการปรับใช้ของเราทำให้เราจำเป็นต้องตรวจสอบว่ามันเป็นปัญหากับ UI - หรือกับการทดสอบ เพื่อแก้ไขสิ่งนี้เราจึงเริ่มคิดถึงวิธีที่เราสามารถตรวจจับได้ว่าการทดสอบอาจล้มเหลวก่อนที่จะส่งไปยังสาขาโค้ดการผลิตของเรา
การทดสอบการเผาไหม้ช่วยอย่างไร
เข้ามาในการทดสอบการเผาไหม้ การทดสอบการเผาไหม้คือกระบวนการที่ใช้ทดสอบบางสิ่งในสภาพที่เข้มงวดหรือตึงเครียดมากขึ้น มันยังถูกเรียกว่าการทดสอบความเครียดหรือการทดสอบภาระขึ้นอยู่กับวิธีหรือพื้นที่ที่เฉพาะเจาะจงที่กำลังทดสอบอยู่
ที่ Guru เราใช้การทดสอบการเผาไหม้เป็นส่วนหนึ่งของชุด Cypress ของเราสำหรับการทดสอบใหม่หรือที่ปรับเปลี่ยนในการปรับแต่งของเรา ก่อนที่การทดสอบเหล่านี้จะสามารถรวมได้เราจะทำการทดสอบหลายครั้งรวดติดต่อกันและทั้งหมดต้องผ่านเพื่อที่จะไปยังขั้นตอนถัดไปในสายการสร้าง CircleCI ของเรา
ขั้นตอนนี้เกิดขึ้นทันทีที่ก่อนที่เราจะทำการทดสอบทั้งชุด Cypress ทั้งหมด ข้อดีของลำดับนี้คือถ้าขั้นตอนการทดสอบการเผาไหม้ผลิตความล้มเหลวเราสามารถทำเครื่องหมายการตรวจสอบทั้งหมดเป็นความล้มเหลวได้ตั้งแต่ต้น การข้ามเศษส่วนที่เหลือของชุดช่วยให้เราประหยัดเวลาและลดจำนวนรอบที่ใช้ในการรับรองว่าการทดสอบที่เพิ่มเข้ามาใหม่เป็นไปตามความเชื่อถือได้และทนทานตามที่เราต้องการ
เพื่อค้นหาไฟล์ที่เราต้องการเราจึงใช้ git diff ในสาขาปัจจุบันและส่งผลลัพธ์เป็นพารามิเตอร์ไปยังเครื่องมือที่เรียกว่า cypress-repeat ซึ่งช่วยให้เรารันการทดสอบเหล่านั้นจำนวนตามที่กำหนดได้อย่างมีประสิทธิภาพทำให้การทดสอบการเผาไหม้เป็นขั้นตอนหนึ่งในชุดการทดสอบแบบ end-to-end ของเรา
ผลลัพธ์
การทำการปรับปรุงนี้ในแผนการทดสอบของเราได้ให้ผลลัพธ์ที่ดีอย่างมาก สำหรับเราแล้วการเพิ่มการทดสอบการเผาไหม้สามารถลดเวลาที่ใช้ในการค้นหาการทดสอบที่ไม่น่าเชื่อถือได้มากถึง 30 นาที มันยังช่วยเพิ่มเวลาในการตอบสนองสำหรับการเพิ่มฟังก์ชันใหม่ เนื่องจากการทดสอบใหม่ที่เพิ่มเข้ามาถูกทดสอบก่อนพวกเขาช่วยให้เราสามารถตรวจสอบความมั่นคงก่อนที่จะดำเนินการต่อไปยังการสร้างพื้นที่อื่น ๆ
โดยรวมแล้วการมุ่งเน้นอย่างต่อเนื่องในการทำให้กระบวนการทดสอบของเรามีประสิทธิภาพมากขึ้นและแข็งแกร่งขึ้นช่วยเพิ่มความมั่นใจของทีมวิศวกรรมทั้งหมดในการส่งฟีเจอร์ใหม่อย่างรวดเร็ว เรากำลังแก้ไขข้อบกพร่องได้รวดเร็วยิ่งขึ้นและทำให้มันง่ายขึ้นในการทำงานข้ามฐานโค้ดทั้งหมดของเรา เราหวังว่าบทความนี้จะช่วยผู้ใช้ Cypress คนอื่น ๆ ในการสร้างการทดสอบที่ดีขึ้นและทำให้ทีมทั้งหมดทำงานได้อย่างมีประสิทธิภาพมากขึ้น
เรามุ่งมั่นในการแชร์ความรู้ที่ Guru และเมื่อเราค้นพบสิ่งใหม่ที่มีประโยชน์เราต้องการให้โลกรู้! ทีมวิศวกรรมของเราใช้ Cypress ในกระบวนการทดสอบและ QA ของพวกเขา พวกเขาได้ค้นพบวิธีใหม่ในการช่วยให้การทดสอบการเผาไหม้ดียิ่งขึ้นและพวกเขาต้องการแบ่งปันกระบวนการใหม่และที่พัฒนาขึ้นของพวกเขากับวิศวกรและผู้ทดสอบคนอื่น
ในปีที่ผ่านมาเราได้มุ่งเน้นการเพิ่มครอบคลุมการทดสอบของเรา - โดยเฉพาะการทดสอบแบบ end-to-end ที่รับประกันว่าแต่ละส่วนของการทำงานของผลิตภัณฑ์ของเราทำงานอย่างถูกต้องเมื่อเราทำการปรับปรุงโค้ด สำหรับประเภทการทดสอบนี้เราจะใช้เครื่องมือที่ชื่อว่า Cypress ซึ่งเลียนแบบพฤติกรรมของผู้ใช้ด้วยแอพเว็บและส่วนขยายของ Google Chrome ของเรา ชุดการทดสอบนี้จะทำงานในทุกคำขอที่ดึงเพื่อให้แน่ใจว่าโค้ดใหม่ไม่ได้ทำลายสิ่งต่าง ๆ ใน UI ของเรา เรายังต้องการบล็อกการปล่อยไม่ให้เกิดขึ้นหากชุด Cypress ของเราล้มเหลวในสาขาการผลิตของเรา
สิ่งที่เรามองหาในการทดสอบแบบดั้งเดิม
ปัญหาหนึ่งที่เราต้องจัดการคือการเห็นการทดสอบบางรายการล้มเหลวแต่ไม่ใช่ในเหตุผลที่เกี่ยวข้องกับ UI หรือโค้ด แล้ว Cypress ช่วยเราในกรณีเหล่านี้ได้อย่างไร? เรามี Cypress ทำหน้าที่เป็นผู้ใช้ซึ่งพฤติกรรมของเราสามารถกำหนดได้ มีตัวแปรหลายตัวที่อาจทำให้ Cypress บอกเราว่ามีความล้มเหลวแต่จากมุมมองของผู้ใช้ดูเหมือนจะไม่มีอะไรผิดปกติ
ตัวอย่างเช่น อาจมีการทดสอบที่บอกว่า "ไปที่ส่วนนี้ของแอพเว็บ > เพิ่มการ์ด Guru ใหม่ > คาดว่าจะเห็นสถานะหลังการสร้าง" หากสถานะการโหลดของการสร้างการ์ดช้ากว่าที่มันควรจะเป็นและ Cypress เริ่มมองหาสถานะหลังสร้างก่อนที่มันจะอยู่ที่นั่นการทดสอบนี้อาจล้มเหลว (ส่วนมากการทดสอบนี้จะผ่าน) ถ้ามันทดสอบผ่านครั้งเดียวในคำขอที่ดึงเราอาจรวมโค้ดที่อาจมีปัญหาได้ แต่เราไม่รู้ว่ามันจะเป็นอย่างไร; การทดสอบที่ผ่านเป็นการรับประกันว่าโค้ดถูกต้องไม่ได้
ประเภทสถานการณ์เช่นนี้ทำให้ความน่าเชื่อถือของครอบคลุมการทดสอบของเราลดลง ดังนั้นเมื่อมีการล้มเหลวของการทดสอบเกิดขึ้นในสายการปรับใช้ของเราทำให้เราจำเป็นต้องตรวจสอบว่ามันเป็นปัญหากับ UI - หรือกับการทดสอบ เพื่อแก้ไขสิ่งนี้เราจึงเริ่มคิดถึงวิธีที่เราสามารถตรวจจับได้ว่าการทดสอบอาจล้มเหลวก่อนที่จะส่งไปยังสาขาโค้ดการผลิตของเรา
การทดสอบการเผาไหม้ช่วยอย่างไร
เข้ามาในการทดสอบการเผาไหม้ การทดสอบการเผาไหม้คือกระบวนการที่ใช้ทดสอบบางสิ่งในสภาพที่เข้มงวดหรือตึงเครียดมากขึ้น มันยังถูกเรียกว่าการทดสอบความเครียดหรือการทดสอบภาระขึ้นอยู่กับวิธีหรือพื้นที่ที่เฉพาะเจาะจงที่กำลังทดสอบอยู่
ที่ Guru เราใช้การทดสอบการเผาไหม้เป็นส่วนหนึ่งของชุด Cypress ของเราสำหรับการทดสอบใหม่หรือที่ปรับเปลี่ยนในการปรับแต่งของเรา ก่อนที่การทดสอบเหล่านี้จะสามารถรวมได้เราจะทำการทดสอบหลายครั้งรวดติดต่อกันและทั้งหมดต้องผ่านเพื่อที่จะไปยังขั้นตอนถัดไปในสายการสร้าง CircleCI ของเรา
ขั้นตอนนี้เกิดขึ้นทันทีที่ก่อนที่เราจะทำการทดสอบทั้งชุด Cypress ทั้งหมด ข้อดีของลำดับนี้คือถ้าขั้นตอนการทดสอบการเผาไหม้ผลิตความล้มเหลวเราสามารถทำเครื่องหมายการตรวจสอบทั้งหมดเป็นความล้มเหลวได้ตั้งแต่ต้น การข้ามเศษส่วนที่เหลือของชุดช่วยให้เราประหยัดเวลาและลดจำนวนรอบที่ใช้ในการรับรองว่าการทดสอบที่เพิ่มเข้ามาใหม่เป็นไปตามความเชื่อถือได้และทนทานตามที่เราต้องการ
เพื่อค้นหาไฟล์ที่เราต้องการเราจึงใช้ git diff ในสาขาปัจจุบันและส่งผลลัพธ์เป็นพารามิเตอร์ไปยังเครื่องมือที่เรียกว่า cypress-repeat ซึ่งช่วยให้เรารันการทดสอบเหล่านั้นจำนวนตามที่กำหนดได้อย่างมีประสิทธิภาพทำให้การทดสอบการเผาไหม้เป็นขั้นตอนหนึ่งในชุดการทดสอบแบบ end-to-end ของเรา
ผลลัพธ์
การทำการปรับปรุงนี้ในแผนการทดสอบของเราได้ให้ผลลัพธ์ที่ดีอย่างมาก สำหรับเราแล้วการเพิ่มการทดสอบการเผาไหม้สามารถลดเวลาที่ใช้ในการค้นหาการทดสอบที่ไม่น่าเชื่อถือได้มากถึง 30 นาที มันยังช่วยเพิ่มเวลาในการตอบสนองสำหรับการเพิ่มฟังก์ชันใหม่ เนื่องจากการทดสอบใหม่ที่เพิ่มเข้ามาถูกทดสอบก่อนพวกเขาช่วยให้เราสามารถตรวจสอบความมั่นคงก่อนที่จะดำเนินการต่อไปยังการสร้างพื้นที่อื่น ๆ
โดยรวมแล้วการมุ่งเน้นอย่างต่อเนื่องในการทำให้กระบวนการทดสอบของเรามีประสิทธิภาพมากขึ้นและแข็งแกร่งขึ้นช่วยเพิ่มความมั่นใจของทีมวิศวกรรมทั้งหมดในการส่งฟีเจอร์ใหม่อย่างรวดเร็ว เรากำลังแก้ไขข้อบกพร่องได้รวดเร็วยิ่งขึ้นและทำให้มันง่ายขึ้นในการทำงานข้ามฐานโค้ดทั้งหมดของเรา เราหวังว่าบทความนี้จะช่วยผู้ใช้ Cypress คนอื่น ๆ ในการสร้างการทดสอบที่ดีขึ้นและทำให้ทีมทั้งหมดทำงานได้อย่างมีประสิทธิภาพมากขึ้น
ได้สัมผัสพลังของแพลตฟอร์ม Guru โดยตรง - เข้าร่วมทัวร์ผลิตภัณฑ์ของเราอย่างแบบอินเทอร์แอคทีฟ
ไปทัวร์
