อีเมลยืนยันคือส่วนหนึ่งของขั้นตอนสมัครสมาชิกที่การทดสอบผ่านเบราว์เซอร์ทำคนเดียวไม่ได้ ต้องมีบางอย่างถือที่อยู่ รับข้อความ และส่งรหัสกลับให้งานทดสอบ API อีเมลชั่วคราวทำหน้าที่นั้น: ชุดทดสอบขอให้บริการสร้างกล่องทาง HTTP อ่านสิ่งที่ส่งเข้ามา แล้วทิ้งกล่องเมื่อกรณีทดสอบจบลง ไม่มีเบราว์เซอร์ ไม่มีกล่องเมลของคนจริงที่ใช้ร่วมกัน และไม่มีการคัดลอกวางด้วยมือ
บทความนี้ว่าด้วยฝั่ง API ของการจัดวางแบบนั้น ไม่ใช่การชี้ให้แอปพลิเคชันส่งไปยังจุดรับในเครื่อง ซึ่งเป็นเรื่องของการดักจับอีเมลใน CI เพราะสองวิธีนี้แก้คนละปัญหา การดักจับในเครื่องพิสูจน์ว่าแอปพลิเคชันส่งอะไรออกไป ส่วน API อีเมลพิสูจน์ว่าอะไรมาถึงจริงตามเส้นทางส่งจริง ยังที่อยู่ที่งานทดสอบเป็นเจ้าของ
ทำไมจึงควรใช้ API อีเมลในงานทดสอบ?
เพราะทางเลือกอื่นมีเพียงกล่องเมลของคนจริงหรือไม่ก็ไม่มีอะไรเลย
กล่องที่ใช้ร่วมกันเป็นอุปกรณ์ทดสอบที่แย่ หลายรอบรันอ่านกล่องเดียวกัน ข้อความจากรอบก่อนยังค้างอยู่ และที่อยู่ก็สะสมข้อความที่ไม่มีงานทดสอบใดขอมา ทุกการยืนยันจึงต้องเดาว่าข้อความใดเป็นของกรณีปัจจุบัน และความไม่แน่นอนก็เกิดตรงการเดานี่เอง
การเก็บข้อมูลจากหน้าเว็บของผู้ให้บริการด้วยเบราว์เซอร์เป็นทางเลือกที่แย่ข้อที่สอง เพราะทำให้งานทดสอบขึ้นกับโครงสร้างหน้าเว็บที่เปลี่ยนโดยไม่บอกล่วงหน้า ขึ้นกับสถานะของเซสชัน และขึ้นกับหน้าล็อกอินที่ชุดทดสอบต้องคอยดูแล พอผู้ให้บริการเปลี่ยนสไตล์ปุ่ม ชุดทดสอบที่เคยเขียวก็กลายเป็นแดงด้วยเหตุที่ไม่เกี่ยวกับผลิตภัณฑ์เลย
API อีเมลตัดปัญหาทั้งสองข้อออกไป ที่อยู่ถูกสร้างขึ้นสำหรับกรณีนี้ มันว่างเปล่าโดยธรรมชาติ และอ่านผ่านอินเทอร์เฟซที่มั่นคงซึ่งงานทดสอบเรียกได้โดยตรง ชุดทดสอบจึงไม่ต้องสนใจว่าผู้ให้บริการหน้าตาเป็นอย่างไร สนแค่ว่าสัญญายังคงอยู่ นั่นคือสร้าง รับ อ่าน ลบ
ยังมีเหตุผลด้านความเป็นส่วนตัวด้วย ที่อยู่ที่สร้างผ่าน API ไม่ได้แทนใคร มันไม่ใช่กล่องเมลของบุคคล ไม่ใช่ที่ที่ข้อความจริงจะตกถึง และมันถูกทิ้งไปพร้อมรอบรัน
งานทดสอบต้องใช้ปลายทางใดจริง ๆ?
API อีเมลอาจเปิดเส้นทางเป็นสิบ ๆ แต่ไคลเอนต์ทดสอบต้องการเพียงสี่การกระทำ และการตั้งชื่อให้ตรงกับที่ชุดทดสอบจะใช้ก็ช่วยได้
การสร้างคืนค่าที่อยู่และตัวจัดการ ที่อยู่คือสิ่งที่แอปพลิเคชันที่กำลังทดสอบถูกบอกให้ส่งไป ส่วนตัวจัดการ ซึ่งมักเป็นโทเคนหรือตัวระบุ คือสิ่งที่งานทดสอบใช้ถามถึงกล่องนั้นในการเรียกครั้งต่อ ๆ ไป ชุดทดสอบควรถือทั้งคู่เป็นวัตถุเดียวกัน และไม่สร้างตัวจัดการขึ้นใหม่จากที่อยู่ เพราะผู้ให้บริการมีสิทธิ์ทำให้ทั้งสองไม่เกี่ยวข้องกันเลย
การลิสต์คืนค่าบทสรุปแทนตัวข้อความ คือหนึ่งรายการต่อหนึ่งข้อความ พร้อมตัวระบุ ผู้ส่ง หัวเรื่อง และเวลาที่มาถึง นี่คือการเรียกที่ลูปรอควรใช้ เพราะมันถูกและเพียงพอที่จะตอบคำถามเดียวที่สำคัญในช่วงต้น นั่นคือมีอะไรมาถึงแล้วหรือยัง
การอ่านคืนค่าข้อความหนึ่งฉบับเต็ม ทั้งส่วนข้อความล้วนและ HTML รหัสอยู่ตรงนั้น และนี่คือการเรียกที่ควรทำหลังการลิสต์รายงานว่าพบรายการที่ตรงแล้วเท่านั้น
การล้างลบข้อความออกจากกล่องหรือลบกล่องทั้งใบ งานทดสอบต้องใช้ด้วยสองเหตุผล คือเพื่อรีเซ็ตระหว่างความพยายามโดยไม่ต้องสร้างที่อยู่ใหม่ และเพื่อเก็บกวาดเมื่อกรณีจบลง
บางบริการเพิ่มปลายทางการรอหรือการรอแบบยาว ที่ถือการเชื่อมต่อไว้จนมีข้อความมาถึงหรือครบเวลาที่กำหนด มันสะดวก แต่ไคลเอนต์ก็ยังควรถอยกลับไปใช้การลิสต์ได้ เพราะการเรียกรอเป็นส่วนที่มักติดเพดานอัตรามากที่สุด
รออ่านรหัสอย่างไรไม่ให้ผลไม่นิ่ง
ความผิดพลาดที่พบบ่อยที่สุดในงานทดสอบแบบนี้คือการรอด้วยเวลาคงที่ จำนวนวินาทีคงที่คือการเดา สั้นเกินไปเมื่อการส่งช้า ยาวเกินความจำเป็นเมื่อการส่งเร็ว และผิดทั้งสองทางบนเครื่อง CI ที่มีงานหนัก แทนที่ด้วยลูปที่เรียกลิสต์ ตรวจหาสิ่งที่ตรง และคืนค่าทันทีที่พบ พร้อมเพดานที่ทำให้การทดสอบล้มเหลวแทนที่จะปล่อยงานค้าง
การจับคู่คืออีกครึ่งหนึ่งของปัญหา ข้อความที่งานทดสอบต้องการคือฉบับที่ส่งถึงที่อยู่ซึ่งกรณีนี้สร้างขึ้น และถ้ากล่องเก็บเมลได้มากกว่าหนึ่งชนิด ก็คือฉบับที่หัวเรื่องมีชิ้นส่วนที่มั่นคง ควรเลือกอันที่ใหม่ที่สุด เพื่อให้การส่งซ้ำจากการลองใหม่ไม่ทำให้การอ่านสับสน และอย่าเอาฉบับแรกแบบไม่มีเงื่อนไข เพราะบนที่อยู่ที่ใช้ซ้ำ นั่นคือวิธีที่รหัสเก่าถูกตรวจสอบจนผ่าน
การดึงรหัสควรมีจุดยึด เนื้อความอาจมีเลขอ้างอิง เวลาประทับ และราคา แล้วตัวแยกวิเคราะห์ที่คว้าเลขชุดแรกก็อาจคว้าเอาอย่างอื่นแทนรหัส ให้มองหาถ้อยคำที่นำเข้ารหัส อ่านรหัสจากบริเวณนั้น และล้มเหลวโดยแนบเนื้อความมาด้วยเมื่อไม่พบอะไรที่ตรง
สุดท้าย ให้เคารพเพดานการส่งซ้ำ ขั้นตอนรหัสมักอนุญาตให้ส่งได้เพียงไม่กี่ครั้งในหน้าต่างเวลาสั้น ๆ และเพดานนั้นเป็นส่วนหนึ่งของพฤติกรรมที่กำลังทดสอบ งานทดสอบที่กดปุ่มซ้ำเพื่อเอารหัสใหม่จะถูกปฏิเสธในที่สุดและล้มเหลวด้วยเหตุที่ผิด ให้ลองใหม่โดยอ่านกล่องอีกครั้ง ไม่ใช่โดยกระตุ้นให้ส่งข้อความใหม่
นำไปต่อกับชุดทดสอบปลายทางถึงปลายทางหรือ CI
รูปแบบที่สะอาดคืออุปกรณ์ทดสอบ ก่อนที่ขั้นตอนจะเริ่ม อุปกรณ์ทดสอบจะสร้างกล่องและคืนค่าที่อยู่ งานทดสอบขับเคลื่อนแอปพลิเคชันด้วยที่อยู่นั้น หลังแอปพลิเคชันยืนยันว่าส่งแล้ว การยืนยันจะอ่านกล่องและดึงรหัสออกมา เมื่อกรณีจบลง อุปกรณ์ทดสอบจะลบกล่องทิ้ง
ทำให้ไคลเอนต์เล็กและฉีดเข้าได้ โมดูลเดียวห่อสี่การเรียก งานทดสอบขึ้นกับโมดูลนั้น ไม่ใช่กับ HTTP ดิบที่กระจัดกระจายทั่วชุดทดสอบ วิธีนี้ทำให้สลับเป็นตัวแทนปลอมในยูนิตเทสต์ได้ และชี้ชุดทดสอบเดิมไปยังผู้ให้บริการรายอื่นได้โดยไม่ต้องเขียนการยืนยันใหม่
ใน CI ข้อมูลรับรองควรอยู่ในที่เก็บความลับของงาน ไม่ใช่ในรีโพซิทอรีและไม่ใช่ในบรรทัดล็อก ให้แต่ละงานหรือแต่ละเวิร์กเกอร์ที่รันขนานมีกล่องของตัวเอง และเติมคำนำหน้าที่บ่งชี้รอบรันลงในที่อยู่ที่สร้างขึ้น เพื่อให้ข้อความที่หลงมาถูกระบุที่มาได้ด้วยการดู และตั้งเวลาหมดอายุของไคลเอนต์ให้ต่ำกว่าเวลาหมดอายุของงานเอง เพื่อให้การรอที่ค้างล้มเหลวพร้อมข้อความชัดเจน แทนที่จะเป็นการยกเลิกงานอย่างกระทันหัน
ลองใหม่ที่การอ่าน ไม่ใช่ทั้งขั้นตอน ถ้ารหัสยังไม่มา ให้รอแล้วอ่านใหม่ การรันสมัครซ้ำจะสร้างข้อความที่สองและสร้างตัวเลือกที่สองให้การยืนยันด้วย และกัน API อีเมลออกจากขั้นตอนการใช้งานจริง เพราะมันคือโครงสร้างพื้นฐานสำหรับทดสอบ และชุดทดสอบไม่ควรส่งถึงลูกค้าจริงจากมันได้เลย
ขั้นตอนรอบ ๆ รหัส ซึ่งไม่ใช่กลไกการอ่านรหัส อยู่ในการทดสอบขั้นตอนยืนยันอีเมล และขั้นตอนการแยกวิเคราะห์โดยเฉพาะเป็นหัวข้อของทดสอบรหัสยืนยันอัตโนมัติ
การแยกและการเก็บกวาด
หนึ่งที่อยู่ต่อหนึ่งกรณีคือกฎที่กันความล้มเหลวข้ามการทดสอบส่วนใหญ่ไว้ มันตัดความจำเป็นในการคิดว่าข้อความใดเป็นของใคร และทำให้คำถามเรื่องความสดใหม่หายไป เพราะกล่องได้รับข้อความของกรณีเดียวมาตลอด
การเก็บกวาดควรชัดเจนและไม่มีเงื่อนไข ให้ลบกล่องในขั้นตอนรื้อที่รันไม่ว่ากรณีจะผ่านหรือล้มเหลว ไม่ใช่แค่เส้นทางที่ราบรื่น การพึ่งอายุของกล่องจากผู้ให้บริการเพียงอย่างเดียวเป็นความผิดพลาด ข้อความอาจค้างนานพอให้รอบรันในภายหลังบนเครื่องเดียวกันอ่านเจอ และอายุนั้นเป็นเพียงความสะดวก ไม่ใช่การรับประกัน
ถ้าการเก็บกวาดล้มเหลว ให้บันทึกไว้แล้วปล่อยให้ชุดทดสอบทำงานจนจบ ข้อผิดพลาดในการเก็บกวาดเป็นเรื่องที่ควรรู้ แต่ไม่เหมือนกับข้อบกพร่องของผลิตภัณฑ์ และการทำให้รอบรันล้มเหลวเพราะเรื่องนี้จะสอนทีมให้มองข้ามความล้มเหลวของขั้นตอนรื้อ ให้ถือทุกอย่างที่ที่อยู่ได้รับเป็นข้อมูลทดสอบ มันมีอยู่เพื่อการยืนยันครั้งเดียว ไม่ควรส่งออกหรือแชร์ และไม่ควรถือเป็นช่องทางติดต่อของใคร
ขีดจำกัดและข้อควรระวัง
API อีเมลยังคงเป็นการพึ่งพาบุคคลที่สาม และขีดจำกัดของมันก็กลายเป็นขีดจำกัดของคุณ เพดานอัตราต่อนาทีอาจปฏิเสธการสร้างจำนวนมากจากรอบรันขนานขนาดใหญ่ โควตาจำกัดว่ามีที่อยู่พร้อมกันได้กี่แห่ง ข้อความอาจล่าช้าได้ และข้อความที่ล่าช้าก็ดูเหมือนข้อความที่หายไปจนกว่าจะมาถึง
โดเมนชั่วคราวยังถูกบล็อกอย่างกว้างขวาง โดเมนของผู้ให้บริการอาจถูกปฏิเสธโดยแบบฟอร์มสมัครที่คุณกำลังทดสอบเอง ซึ่งเปลี่ยนการทดสอบที่ชอบด้วยเหตุผลให้กลายเป็นความล้มเหลวที่สับสน เมื่อเจอแบบนั้น คำตอบไม่ใช่การทำข้อยกเว้นให้ผู้ให้บริการ แต่คือการทำความเข้าใจว่าผลิตภัณฑ์ที่ทดสอบปฏิเสธที่อยู่ชั่วคราวโดยเจตนาหรือไม่ แล้วทดสอบพฤติกรรมนั้นอย่างตั้งใจ
สรุปตามจริงคือ API อีเมลเป็นเครื่องมือที่ถูกต้องสำหรับยืนยันว่าอะไรมาถึง ส่วนการยืนยันว่าแอปพลิเคชันส่งอะไรออกไป จุดรับในเครื่องเร็วกว่าและไม่มีโควตา ชุดทดสอบที่โตเต็มที่ส่วนใหญ่ใช้ทั้งสองอย่าง คือดักจับในเครื่องสำหรับการยืนยันส่วนใหญ่ และใช้ API อีเมลเฉพาะที่เส้นทางส่งจริงเป็นสิ่งที่กำลังทดสอบ
ขั้นตอนถัดไป
ลองหางานทดสอบหนึ่งรายการในชุดของคุณที่รออ่านรหัสจากกล่องที่ใช้ร่วมกัน แล้วเปลี่ยนเป็นอุปกรณ์ทดสอบที่สร้างที่อยู่ใหม่จาก API อีเมล บันทึกที่อยู่ไว้กับรอบรัน ลบมันในขั้นตอนรื้อ แล้วดูว่าความไม่นิ่งที่คุณเคยยอมรับไว้นั้นหายไปมากแค่ไหน เมื่อต้องใช้กล่องจริงด้วยมือ หน้าอีเมลชั่วคราวสร้างให้ในพริบตา และที่อยู่ที่มันแจกจ่ายนั้นเป็นนั่งร้านสำหรับรอบรัน ไม่ใช่ตัวตนจริง