Selenium สำหรับทดสอบ API: ทำได้ไหม และควรทำหรือไม่

Selenium เป็นเฟรมเวิร์กสำหรับการทำงานอัตโนมัติของเบราว์เซอร์ มันขับเคลื่อน Chrome, Firefox และเบราว์เซอร์อื่น ๆ ในลักษณะเดียวกับที่มนุษย์ทำ: คลิกปุ่ม, กรอกแบบฟอร์ม, อ่านหน้าเว็บที่แสดงผล มันเป็นเครื่องมือมาตรฐานสำหรับการทดสอบ UI แบบ end-to-end และมันทำงานได้ดีมากในส่วนนั้น

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

ทำไม Selenium และการทดสอบ API จึงไม่เข้ากัน

การทดสอบ API จะส่งคำขอ HTTP โดยตรงไปยังเซิร์ฟเวอร์และตรวจสอบการตอบกลับ: รหัสสถานะ, เฮดเดอร์, เนื้อหา, และเวลาที่ใช้ ไม่มีการเกี่ยวข้องกับส่วนติดต่อผู้ใช้ การทดสอบควรจะรวดเร็ว, แยกส่วน (isolated) และมีค่าใช้จ่ายต่ำในการรันหลายพันครั้ง

Selenium ทำสิ่งที่ตรงกันข้ามโดยการออกแบบ มันเปิดเบราว์เซอร์จริง, โหลดหน้าเว็บ และรอให้ JavaScript แสดงผล เบราว์เซอร์นั้นคือจุดประสงค์ทั้งหมดเมื่อคุณกำลังทดสอบ UI และเป็นค่าใช้จ่ายส่วนเกินล้วนๆ เมื่อคุณกำลังทดสอบ API คำขอที่ไคลเอ็นต์เฉพาะส่งในไม่กี่สิบมิลลิวินาทีจะกลายเป็นการดำเนินการที่ใช้เวลาหลายวินาทีทันทีที่คุณเกี่ยวข้องกับกระบวนการเบราว์เซอร์, เซสชัน WebDriver และการแสดงผลหน้าเว็บ

ยังมีความไม่เข้ากันที่ลึกซึ้งกว่านั้นด้วย API ทั้งหมดของ Selenium เกี่ยวกับองค์ประกอบบนหน้าเว็บ: ค้นหาปุ่มนี้, อ่านข้อความนี้, รอองค์ประกอบนี้ การตอบกลับ HTTP ไม่ใช่หน้าเว็บ ไม่มี DOM ดังนั้น Selenium จึงไม่มีประโยชน์สำหรับการตรวจสอบ JSON body, การยืนยัน header หรือการตรวจสอบรหัสสถานะ คุณจะลงเอยด้วยการพยายามหลีกเลี่ยงข้อจำกัดของเครื่องมือแทนที่จะใช้งานมันอย่างตรงไปตรงมา

ค่าใช้จ่ายไม่ได้มีแค่เรื่องความเร็วเท่านั้น การทดสอบที่ใช้เบราว์เซอร์ขึ้นชื่อว่าไม่เสถียร (flaky) มักล้มเหลวเพราะหน้าเว็บใช้เวลาในการแสดงผลนานขึ้นเล็กน้อย, เพราะเซสชัน WebDriver หลุด หรือเพราะการอัปเดตเบราว์เซอร์ทำให้การกำหนดเวลาบางอย่างเปลี่ยนไป การทดสอบ API ควรจะเป็นแบบกำหนดผลได้ (deterministic): คำขอเดียวกันควรให้การตอบกลับที่เหมือนกัน และความล้มเหลวหมายถึงมีบางอย่างที่เสียจริง การส่งผ่านการตรวจสอบ API ผ่าน Selenium ทำให้ความไม่เสถียรของเบราว์เซอร์ทั้งหมดเข้ามาสู่ชั้นที่ไม่ควรมีความไม่เสถียรเลย เมื่อเวลาผ่านไป ชุดการทดสอบที่ไม่เสถียรจะทำให้ทีมละเลย build ที่เป็นสีแดง ซึ่งเป็นการบิดเบือนจุดประสงค์ของการทดสอบ ความแตกต่างระหว่าง validation และ verification เป็นมุมมองที่ดีในที่นี้: Selenium ตรวจสอบประสบการณ์ที่แสดงผล ในขณะที่การทดสอบ API ตรวจสอบความถูกต้องของสัญญาพื้นฐาน (contract)

"การทดสอบ API ด้วย Selenium" หมายถึงอะไรกันแน่

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

ตัวเลือกที่หนึ่ง: ใช้ JavaScript executor ของ Selenium Selenium สามารถรัน JavaScript แบบใดก็ได้ในเบราว์เซอร์ที่ควบคุม เบราว์เซอร์สมัยใหม่มี fetch API ดังนั้นคุณสามารถขอให้เบราว์เซอร์ส่งคำขอและส่งผลลัพธ์กลับไปยังโค้ดทดสอบของคุณได้:

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

วิธีนี้ใช้งานได้ แต่ก็หมายความว่าคุณได้เริ่มต้นเบราว์เซอร์, WebDriver และ JavaScript bridge เพียงเพื่อทำการเรียก HTTP ครั้งเดียว ซึ่งไคลเอ็นต์ HTTP ปกติจะทำได้โดยตรง คุณยังได้รับข้อจำกัดของเบราว์เซอร์ เช่น CORS ซึ่งการทดสอบ API แบบ server-to-server ไม่จำเป็นต้องกังวลถึงเลย

ตัวเลือกที่สอง: เพิกเฉยต่อ Selenium และใช้ไลบรารี HTTP จริงควบคู่ไปกับมัน ในโปรเจกต์ Java หมายถึงการจับคู่ Selenium กับ REST Assured สำหรับส่วนของ API:

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

สังเกตว่าการทดสอบ API จริงๆ ในที่นี้ทำโดย REST Assured ทั้งหมด Selenium ไม่ได้มีส่วนร่วมใดๆ ไลบรารีทั้งสองตัวนี้บังเอิญอยู่ในโปรเจกต์เดียวกัน ซึ่งก็ไม่เป็นไร แต่นี่ไม่ใช่ "การทดสอบ API ด้วย Selenium" มันคือการทดสอบ API ด้วยไลบรารีทดสอบ API ที่เหมาะสม โดยมี Selenium อยู่ในโปรเจกต์สำหรับการทดสอบ UI ที่ไม่เกี่ยวข้อง

เมื่อการผสมผสานเครื่องมือทั้งสองอย่างเป็นเหตุเป็นผล

มีกรณีที่สมเหตุสมผลหนึ่งเดียวสำหรับการทำงาน HTTP ภายในชุดการทดสอบ Selenium และควรจะทำความเข้าใจให้ชัดเจน การทดสอบ UI ด้วย Selenium มักต้องการการตั้งค่า (setup) หรือการยกเลิก (teardown) ที่รวดเร็วกว่าเมื่อทำผ่าน API มากกว่าผ่านเบราว์เซอร์

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

นั่นคือแนวทางปฏิบัติที่ถูกต้อง การเรียก API เป็นเพียงวิธีการไปสู่เป้าหมาย ไม่ใช่สิ่งที่กำลังถูกทดสอบ การเรียก API ควรยังคงผ่านไคลเอ็นต์ HTTP จริง ไม่ใช่ JavaScript executor ของ Selenium ดังนั้นแม้ในกรณีนี้ Selenium ก็ไม่ได้ทำการทดสอบ API มันกำลังทำการทดสอบ UI และไคลเอ็นต์ HTTP ที่เหมาะสมจะจัดการฝั่ง API

รูปแบบการตั้งค่าผ่าน API นี้เป็นที่แพร่หลายมากพอที่ชุดการทดสอบที่สมบูรณ์ส่วนใหญ่จะนำไปใช้โดยตั้งใจ มันช่วยให้ส่วนที่ขับเคลื่อนด้วยเบราว์เซอร์ที่ช้าของชุดการทดสอบมีขนาดเล็กที่สุดเท่าที่จะทำได้ สงวนไว้สำหรับการเดินทางเพียงไม่กี่ครั้งที่ต้องการหน้าเว็บที่แสดงผลจริงๆ สิ่งอื่นๆ ทั้งหมด รวมถึงการเตรียมข้อมูลทั้งหมดและการตรวจสอบส่วนใหญ่ เกิดขึ้นผ่านการเรียก HTTP ที่รวดเร็ว ผลลัพธ์คือชุดการทดสอบที่ทำงานได้ในไม่กี่นาทีแทนที่จะเป็นชั่วโมง และล้มเหลวด้วยเหตุผลที่แท้จริง สำหรับภาพรวมที่กว้างขึ้นว่า UI และเลเยอร์อัตโนมัติทำงานร่วมกันอย่างไร โปรดดู functional testing versus automated testing

ใช้เครื่องมือที่สร้างมาเพื่อการทดสอบ API โดยเฉพาะ

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

ตัวเลือกของคุณแบ่งออกเป็นหลายกลุ่ม:

หากคุณชอบโค้ด ไลบรารี HTTP เช่น REST Assured ใน Java, requests ใน Python หรือ supertest ใน Node คือตัวเลือกที่เหมาะสม ไลบรารีเหล่านี้จะสร้างคำขอและส่งการตอบกลับให้คุณโดยตรง พร้อมตัวช่วยในการยืนยันที่สร้างขึ้นสำหรับรหัสสถานะและ JSON bodies ไม่มีเบราว์เซอร์, ไม่มี WebDriver และไม่มีการแสดงผล ดังนั้นชุดการทดสอบทั้งหมดจึงทำงานได้อย่างรวดเร็วและจะล้มเหลวก็ต่อเมื่อ API เปลี่ยนแปลงไปเท่านั้น

หากคุณต้องการพื้นที่ทำงานแบบกราฟิก (visual workspace), Apidog คือแพลตฟอร์ม API แบบครบวงจรที่ครอบคลุมการออกแบบ API, การดีบักคำขอ, การจำลองปลายทาง, การสร้างสถานการณ์การทดสอบอัตโนมัติ และการสร้างเอกสาร ทั้งหมดนี้ในโปรเจกต์เดียว คุณสามารถสร้างการยืนยันด้วยภาพหรือด้วยสคริปต์, เชื่อมโยงคำขอเข้ากับขั้นตอนหลายขั้นตอน, รันการวนซ้ำแบบ data-driven และดำเนินการทุกอย่างใน CI นอกจากนี้ยังนำเข้าไฟล์ OpenAPI และ Postman ได้ ทำให้สามารถนำ API ที่มีอยู่เข้ามาได้อย่างรวดเร็ว ไม่มีส่วนใดที่เกี่ยวข้องกับเบราว์เซอร์ เพราะไม่ควรจะมี คุณสามารถ ดาวน์โหลด Apidog เพื่อทดลองใช้กับ API จริงได้

สำหรับทีมที่ต้องการเฟรมเวิร์กที่เน้นโค้ดเป็นหลัก คู่มือเกี่ยวกับ Robot Framework สำหรับการทำงานอัตโนมัติของ API และ การสร้างเฟรมเวิร์กการทดสอบ API อัตโนมัติ จะครอบคลุมแนวทางที่แตกต่างจาก Selenium ซึ่งเหมาะสมกับการทดสอบ HTTP อย่างแท้จริง

ข้อสรุปที่ตรงไปตรงมา

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

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

คำถามที่พบบ่อย

Selenium สามารถทดสอบ REST APIs ได้เลยหรือไม่?

มันสามารถส่งคำขอ HTTP ผ่าน JavaScript executor ของเบราว์เซอร์ได้ ดังนั้นในทางเทคนิคอย่างแคบๆ ก็คือใช่ แต่ Selenium ไม่มีคุณสมบัติสำหรับการตรวจสอบการตอบกลับ, การยืนยัน JSON หรือการตรวจสอบเฮดเดอร์ และมันมีค่าใช้จ่ายส่วนเกินทั้งหมดของเบราว์เซอร์ มันไม่ใช่เครื่องมือทดสอบ REST API และการใช้มันเป็นเครื่องมือดังกล่าวจะสร้างการทดสอบที่ช้าและเปราะบาง

ทำไมบทเรียนบางอย่างถึงแสดง Selenium คู่กับ REST Assured?

เนื่องจาก การทดสอบ API ในบทเรียนเหล่านั้นทำโดย REST Assured ทั้งหมด ซึ่งเป็นไลบรารีการทดสอบ HTTP จริง Selenium เพียงแค่มีอยู่ในโปรเจกต์เดียวกันสำหรับการทดสอบ UI ที่ไม่เกี่ยวข้อง การจับคู่เช่นนั้นก็ใช้ได้ แต่ไม่ได้หมายความว่า Selenium กำลังทดสอบ API ผู้ที่ทดสอบคือ REST Assured

การเรียก API ในการทดสอบ Selenium เป็นสิ่งที่ยอมรับได้หรือไม่?

ได้ สำหรับการตั้งค่า (setup) และการยกเลิก (teardown) การสร้างข้อมูลทดสอบผ่าน API นั้นเร็วกว่าและน่าเชื่อถือกว่าการคลิกผ่าน UI เพื่อสร้างข้อมูลนั้น การเรียก API เป็นตัวสนับสนุนการทดสอบ UI ไม่ใช่สิ่งที่กำลังถูกทดสอบ และควรยังคงใช้ไคลเอ็นต์ HTTP ที่เหมาะสม ไม่ใช่ JavaScript executor ของ Selenium

ฉันควรใช้อะไรแทน Selenium สำหรับการทดสอบ API?

สำหรับการทดสอบแบบ code-first ให้ใช้ไลบรารี HTTP เช่น REST Assured, `requests` ของ Python หรือ `supertest` สำหรับ Node สำหรับพื้นที่ทำงานแบบกราฟิก (visual workspace) แพลตฟอร์ม API เฉพาะเช่น Apidog หรือไคลเอ็นต์เช่น Postman, Insomnia และ Talend API Tester ทั้งหมดนี้ถูกสร้างมาสำหรับ HTTP และหลีกเลี่ยงค่าใช้จ่ายส่วนเกินของเบราว์เซอร์ที่ Selenium บังคับใช้

การใช้ Selenium สำหรับการทดสอบ API ทำให้ CI pipeline ช้าลงหรือไม่?

อย่างมาก การเรียก API ที่ใช้ Selenium แต่ละครั้งจะเริ่มกระบวนการเบราว์เซอร์และเซสชัน WebDriver ทำให้คำขอ HTTP ที่ใช้เวลาไม่ถึงวินาทีกลายเป็นการดำเนินการที่ใช้เวลาหลายวินาที เมื่อรวมกันทั้งชุดการทดสอบ สิ่งนี้ทำให้เกิดการรัน pipeline ที่ยาวนานและไม่เสถียร เครื่องมือทดสอบ API โดยเฉพาะจะทำการตรวจสอบแบบเดียวกันได้เร็วกว่ามาก เพราะมันไม่เคยเปิดเบราว์เซอร์