การเขียนข้อกำหนดแบบ end-to-end นั้นน่าสนใจและสนุกอยู่เสมอ ไม่ต้องพูดถึง จำเป็นต้องทำให้กระบวนการของโค้ด refactoring ปลอดภัยยิ่งขึ้น – พวกมันทำหน้าที่เป็นตัวตรวจจับข้อบกพร่อง บ่อยครั้ง สถานการณ์เหล่านี้เป็นเพียงเอกสารคุณลักษณะเดียวใน codebase
อย่างไรก็ตาม เรายังพบกับความไม่สะดวก: บางครั้ง ใช้เวลานานเกินไปในการตั้งค่าข้อมูลที่เพียงพอ เช่นเดียวกับการจัดการการขึ้นต่อกันของ CSS และการเปลี่ยนแปลงมากมายที่เกิดขึ้นใน CSS และ HTML ในทำนองเดียวกัน การเขียนโค้ดที่อ่านได้และบำรุงรักษาได้ในครั้งเดียวอาจไม่ง่ายนัก
การทดสอบตั้งแต่ต้นทางถึงปลายทางด้วย AngularJS: Tips and Tricks
โชคดีที่ปัญหาเหล่านั้นสามารถแก้ไขได้ วันนี้ เราอยากจะบอกคุณเกี่ยวกับเทคนิคง่ายๆ สองสามอย่างที่คุณสามารถใช้เพื่อจัดการกับประเด็นต่างๆ ที่กล่าวข้างต้น ในขั้นต้น สถานการณ์เหล่านี้เขียนขึ้นสำหรับ Protractor แต่เข้ากันได้อย่างสมบูรณ์แบบกับเฟรมเวิร์กการทดสอบอื่นๆ ที่คุณต้องการใช้งาน
ดูตัวอย่างง่ายๆ ของมาร์กอัปที่มีข้อกำหนดที่เกี่ยวข้องด้านล่าง ทีนี้มาลองอัปเกรดกัน
ทดสอบคุณสมบัติพิเศษแยกกัน
นักพัฒนามักจะทำงานแยกกันกับองค์ประกอบ CSS หรือ HTML และ AngularJS ด้วยเหตุนี้ การขึ้นต่อกันของข้อมูลจำเพาะจำนวนมากจึงเกิดขึ้นขณะทำการเปลี่ยนแปลงมาร์กอัป อันที่จริงนี่เป็นปัญหาใหญ่ที่เกือบทุกทีมต้องเผชิญ ตัวอย่างเช่น เมื่อวิศวกรส่วนหน้าเปลี่ยนชื่อคลาสยูทิลิตี้หรือใช้คลาสอื่นตามการเปลี่ยนแปลง CSS เขาสามารถทำลายข้อกำหนดโดยบังเอิญ
แน่นอน คุณสามารถแก้ไขปัญหานี้ได้โดยการตรวจสอบตัวเลือกข้อมูลจำเพาะแบบ end-to-end อย่างต่อเนื่อง แต่วิธีนี้ไม่สะดวกนัก คุณต้องตรวจสอบการเปลี่ยนแปลงมาร์กอัปที่ทำขึ้น อีกวิธีหนึ่งคือการใช้ความหมายของโมเดลที่เสถียรกับทุกองค์ประกอบ แต่สิ่งนี้ต้องใช้ความพยายามมากเกินไปเช่นกัน ในมุมมองของเรา วิธีแก้ไขคือต้องมีแอตทริบิวต์เฉพาะที่ใช้โดยกรอบการทดสอบเท่านั้น:
คุณลักษณะเหล่านั้นรอบๆ มาร์กอัปอาจดูล้าสมัย ในทางกลับกัน เทคนิคนี้ทำให้เราได้เปรียบหลายประการ มาดูกัน:
- ทุกองค์ประกอบมีชื่อเฉพาะและมีความหมาย
- การใช้การเปลี่ยนแปลงมาร์กอัปจะง่ายขึ้นและปลอดภัยยิ่งขึ้น
- ข้อมูลจำเพาะจะไม่ขึ้นอยู่กับการเปลี่ยนแปลง CSS อีกต่อไป
การจัดการหน้าและออบเจ็กต์ส่วนประกอบ
วัตถุหน้ามักใช้ในการเขียนการทดสอบแบบ end-to-end ด้วยเหตุนี้ ตัวอย่างข้อมูลจำเพาะจึงสะดวกต่อการนำมาใช้และบำรุงรักษามากขึ้น ดูวิธีการกำหนดออบเจ็กต์เพจอย่างง่ายสำหรับข้อมูลจำเพาะด้านล่าง:
ตอนนี้ ตัวอย่างการทดสอบดูสะอาดตายิ่งขึ้นเมื่อไม่มีตัวเลือก CSS
มัณฑนากรถูกกำหนดเป็น:
ผลลัพธ์ที่ได้คือ เราได้ตัวอย่างข้อมูลจำเพาะที่นำมาใช้ใหม่ได้อย่างเต็มที่ ซึ่งไม่ได้ขึ้นอยู่กับการเปลี่ยนแปลง CSS ใดๆ รวมถึง DSL ที่ใช้งานได้ซึ่งกำหนดคลาสของออบเจ็กต์เพจหรือส่วนประกอบ ตอนนี้คุณรู้วิธีอำนวยความสะดวกในการทดสอบแบบ end-to-end แล้ว
บทความเขียนโดย นักพัฒนา Ruby on Rails จากบริษัท Rails Ware – บริษัทเอาท์ซอร์สที่ตั้งอยู่ในยูเครน สหรัฐอเมริกา และโปแลนด์
