การย้ายจาก Keploy สู่ Apidog CLI

ถ้าทีมของคุณเริ่มต้นด้วย Keploy คุณอาจจะชอบสิ่งหนึ่งเกี่ยวกับมัน: คุณรันแอปของคุณ, เรียกใช้ไม่กี่เอนด์พอยต์, และการทดสอบก็ปรากฏขึ้นมา ไม่ต้องเขียนการยืนยัน (assertions) ไม่ต้องทำการจำลอง (stubbing) การพึ่งพา (dependencies) ด้วยตนเอง Keploy จะบันทึกทราฟฟิกจริงในระดับเลเยอร์เครือข่ายและทำการเล่นซ้ำให้คุณ

แล้วทำไมใครบางคนถึงอยากจะย้ายออกจาก Keploy? โดยปกติแล้วมันเกิดจากความต้องการที่แตกต่างกัน การทดสอบที่ถูกบันทึกไว้เป็นสิ่งที่ดีสำหรับการตรวจจับการถดถอยในสิ่งที่เคยเกิดขึ้นแล้ว แต่พวกมันอ่านยาก ตรวจสอบยาก และเป็นเจ้าของร่วมกันในทีมได้ยาก ในบางจุดคุณต้องการการทดสอบที่วิศวกรคนใหม่สามารถเปิดดูได้ใน pull request ทำความเข้าใจได้ในพริบตา และแก้ไขได้ตามวัตถุประสงค์ คุณต้องการข้อมูลการทดสอบที่คุณควบคุมได้ สภาพแวดล้อมที่คุณสามารถสลับได้ด้วยแฟล็ก และเซิร์ฟเวอร์จำลองที่คุณออกแบบเอง แทนที่จะเป็นเซิร์ฟเวอร์ที่ได้มาจากการบันทึก

ปุ่ม

สองแนวคิดที่แตกต่างกัน เปรียบเทียบกันอย่างตรงไปตรงมา

Keploy และ Apidog มีส่วนที่ทับซ้อนกันในคำว่า "การทดสอบ API" แต่พวกมันเป็นเครื่องมือคนละประเภท การแสร้งทำเป็นว่าไม่ต่างกันจะเป็นการทำร้ายคุณ

Keploy เป็นแพลตฟอร์มโอเพนซอร์สสำหรับสร้างแซนด์บ็อกซ์ทดสอบแบบแยกเดี่ยว จุดเด่นของมันคือการบันทึกและเล่นซ้ำ: โดยใช้ eBPF ที่เลเยอร์เครือข่าย มันจะบันทึกการเรียกใช้ API จริงและการพึ่งพา (dependencies) ของพวกมัน (การสอบถามฐานข้อมูล, บริการปลายน้ำ, เหตุการณ์สตรีมมิ่ง) โดยไม่ต้องใช้ SDK และไม่ต้องเปลี่ยนแปลงโค้ด จากทราฟฟิกที่บันทึกไว้นั้น มันจะสร้างกรณีทดสอบและจำลอง (mocks) สำหรับการพึ่งพาเหล่านั้นโดยอัตโนมัติ นอกจากนี้ยังมีเส้นทางการสร้างการทดสอบด้วย AI ที่สร้างชุดทดสอบจาก OpenAPI spec, Postman collection, คำสั่ง cURL หรือเอนด์พอยต์ที่ใช้งานจริง เนื่องจากการบันทึกเกิดขึ้นที่เลเยอร์ eBPF มันจึงไม่ขึ้นกับภาษาใดภาษาหนึ่ง และอาศัย Linux และสิทธิ์ที่สูงขึ้น คุณสามารถอ่านซอร์สโค้ดได้ที่ GitHub

Apidog เป็นแพลตฟอร์ม API แบบครบวงจร: ออกแบบ, ดีบัก, จำลอง, จัดทำเอกสาร, และทดสอบได้ในที่เดียว Apidog CLI (apidog run) จะรันสถานการณ์ทดสอบและคอลเลกชันที่คุณสร้างขึ้น จากเทอร์มินัลของคุณและใน CI/CD มันรองรับการทดสอบแบบขับเคลื่อนด้วยข้อมูล (data-driven testing), การสลับสภาพแวดล้อม (environment switching), รูปแบบรายงานที่หลากหลาย, และรายงานบนคลาวด์ Apidog ยังมีการสร้างกรณีทดสอบด้วย AI แต่จะทำงานจาก API schema และเอนด์พอยต์ของคุณภายในแอป ไม่ใช่โดยการบันทึกทราฟฟิกจาก production

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

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

ขั้นตอนที่ 1: บันทึก API surface ของคุณในรูปแบบ spec

Keploy เริ่มต้นจากแอปที่กำลังทำงานอยู่ ส่วน Apidog เริ่มต้นจากคำอธิบายของ API ของคุณ ดังนั้นภารกิจแรกคือการได้รับคำอธิบายนั้น

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

• สร้าง OpenAPI จากเฟรมเวิร์กของคุณ (เฟรมเวิร์กสมัยใหม่ส่วนใหญ่มีตัวส่งออกหรือไลบรารีที่สร้างมัน)
• ส่งออก Postman collection หากทีมของคุณมีอยู่แล้ว
• รวบรวมคำสั่ง cURL ที่คุณใช้เพื่อเรียกใช้แต่ละเอนด์พอยต์

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

ขั้นตอนที่ 2: นำเข้าสู่ Apidog

ดาวน์โหลด Apidog, สร้างโปรเจกต์, และนำเข้าไฟล์ OpenAPI, Postman collection, หรือคำสั่ง cURL ของคุณ Apidog จะอ่าน spec และเติมข้อมูลเอนด์พอยต์, schema คำขอ, พารามิเตอร์, และโมเดลการตอบกลับ ตอนนี้คุณมีคำจำกัดความที่มีโครงสร้างของทุกเอนด์พอยต์ ซึ่งเป็นพื้นผิวเดียวกันกับที่ Keploy เคยใช้งาน แต่ในรูปแบบที่คุณสามารถแก้ไข, กำหนดเวอร์ชัน, และแบ่งปันได้

นี่คือช่วงเวลาที่ความแตกต่างของแพลตฟอร์มปรากฏขึ้น เอนด์พอยต์ที่นำเข้านั้นไม่ใช่แค่ test fixtures พวกมันคือเอกสารสด, คำขอที่สามารถดีบักได้, และเป็นพื้นฐานสำหรับ mock servers ทั้งหมดนี้มาจากการนำเข้าครั้งเดียว สำหรับคำแนะนำทีละขั้นตอนของชุดเครื่องมือ คู่มือฉบับสมบูรณ์ของ Apidog CLI ครอบคลุมการตั้งค่าทั้งหมด

ขั้นตอนที่ 3: สร้างชุดทดสอบเริ่มต้น จากนั้นสร้างสถานการณ์จริง

นี่คือจุดที่คุณจะได้รับความรวดเร็วบางส่วนที่คุณเคยชอบใน Keploy กลับมา การสร้างกรณีทดสอบด้วย AI ของ Apidog จะอ่าน schema และเอนด์พอยต์ที่คุณนำเข้า และร่างกรณีทดสอบให้คุณ: คำขอที่ถูกต้อง, ค่าขอบเขต, และการตอบกลับความล้มเหลวทั่วไปตาม spec นี่คือจุดเริ่มต้นที่แข็งแกร่ง และช่วยให้คุณเริ่มต้นได้อย่างรวดเร็ว หากคุณต้องการดูว่าสิ่งนี้เปรียบเทียบกับเครื่องมืออื่นๆ อย่างไร รายละเอียดของ เครื่องมือสร้างกรณีทดสอบ AI ที่ดีที่สุด จะช่วยให้คุณเข้าใจบริบทได้

ข้อสังเกตสองประการอย่างตรงไปตรงมา ประการแรก กรณีที่ร่างโดย AI (ไม่ว่าจะเป็นใน Apidog หรือ Keploy) จำเป็นต้องมีการตรวจสอบโดยมนุษย์ ปฏิบัติต่อผลลัพธ์เป็นร่างต้นฉบับ ตัดส่วนที่ไม่เกี่ยวข้องออก และกระชับการยืนยัน ประการที่สอง นี่คือการสร้างจาก spec ไม่ใช่จากพฤติกรรมการรันไทม์ ดังนั้นมันจึงไม่รู้เกี่ยวกับข้อผิดปกติที่ปรากฏขึ้นภายใต้ข้อมูล production จริงเท่านั้น นั่นคือช่องว่างที่ Keploy เติมเต็มด้วยการบันทึก และเป็นช่องว่างที่คุณยอมรับเมื่อคุณย้ายไปใช้การทดสอบที่ออกแบบมา

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

ขั้นตอนที่ 4: ตั้งค่าสภาพแวดล้อมและข้อมูลที่ขับเคลื่อนด้วยข้อมูล

การบันทึกจะเก็บชุดข้อมูลหนึ่งชุดจากการรันหนึ่งครั้ง การทดสอบที่คุณสร้างขึ้นควรทำงานกับสภาพแวดล้อมใดก็ได้ที่มีชุดข้อมูลใดก็ได้

กำหนดสภาพแวดล้อมใน Apidog (local, staging, production) ด้วย Base URL, โทเค็น และตัวแปรของตัวเอง เมื่อรันไทม์ คุณเลือกหนึ่งตัวด้วย -e สำหรับข้อมูลการทดสอบ ให้แนบไฟล์ CSV หรือ JSON และ Apidog จะรันแต่ละสถานการณ์หนึ่งครั้งต่อแถว ดังนั้นสถานการณ์การล็อกอินหนึ่งสถานการณ์จะครอบคลุมชุดข้อมูลยืนยันตัวตนได้หลายสิบชุด คุณชี้ไปยังไฟล์ด้วย -d คู่มือการทดสอบที่ขับเคลื่อนด้วยข้อมูล จะแสดงรูปแบบไฟล์และการผูกตัวแปรโดยละเอียด

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -i 123456 \
  -e "staging" \
  -d ./test-data/login-cases.csv

นี่คือการอัปเกรดที่จับต้องได้เมื่อเทียบกับการบันทึกที่ตายตัว ข้อมูลการทดสอบของคุณคือไฟล์ที่คุณเป็นเจ้าของ สามารถตรวจสอบได้ใน pull requests และขยายได้เมื่อมีกรณีพิเศษใหม่ๆ ปรากฏขึ้น

ขั้นตอนที่ 5: รันใน CI ด้วย apidog run

คำสั่งที่มาแทนที่ keploy test ใน pipeline ของคุณคือ apidog run มันจะรันสถานการณ์ที่คุณสร้างขึ้น ใช้สภาพแวดล้อมและไฟล์ข้อมูลที่เลือก และสร้างรายงาน คุณสามารถสร้างเอาต์พุตในรูปแบบ CLI, HTML และ JSON และส่งผลลัพธ์ไปยังคลาวด์ด้วย --upload-report เพื่อให้ได้ลิงก์ที่สามารถแชร์ได้

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -i 123456 \
  -e "staging" \
  -r html,cli \
  --upload-report

การเชื่อมต่อสิ่งนี้เข้ากับ pipeline ของคุณมีรูปแบบเดียวกับขั้นตอนการทดสอบ CI อื่นๆ: ติดตั้ง CLI, ส่งโทเค็นและ ID สถานการณ์ของคุณ, และทำให้บิลด์ล้มเหลวหากมี non-zero exit คู่มือ CI/CD pipeline และ คู่มือ GitHub Actions จะครอบคลุม YAML ที่ถูกต้อง และ คู่มือรายงานการทดสอบ จะอธิบายวิธีอ่านผลลัพธ์ที่ทีมของคุณจะดูจริง

ขั้นตอนที่ 6: สร้าง Mock Server ที่คุณควบคุม

Keploy มอบ mocks ให้คุณฟรีโดยการบันทึกทราฟฟิกของการพึ่งพาในระหว่างการบันทึก Apidog เลือกเส้นทางอื่น: คุณเป็นคนออกแบบ mock เนื่องจากคุณได้นำเข้า schema ของคุณแล้ว Apidog สามารถสร้าง mock server จาก schema นั้น โดยส่งคืนการตอบสนองตัวอย่างที่สมจริงตามประเภทฟิลด์และกฎที่คุณกำหนด คุณตัดสินใจเรื่อง latency, กรณีเกิดข้อผิดพลาด และ payload ที่แน่นอน

ข้อแลกเปลี่ยนก็เหมือนกับที่อื่นๆ ในคู่มือนี้ Mocks ที่ถูกบันทึกสะท้อนถึงสิ่งที่การพึ่งพาของคุณทำจริง; mocks ที่ออกแบบสะท้อนถึงสิ่งที่คุณตัดสินใจว่าควรจะทำ สำหรับ contract testing และ CI ที่เสถียร mocks ที่ออกแบบมักจะดีกว่าเพราะมันไม่เปลี่ยนแปลงไปตาม production หากคุณต้องการข้อมูลเชิงลึกเพิ่มเติม โปรดดู เครื่องมือ contract testing และ mocking และ การสร้างข้อมูล mock จาก OpenAPI schemas

สิ่งที่คุณยังคงรักษาไว้และสิ่งที่คุณต้องยอมละทิ้ง

โปรดพูดคุยกับทีมของคุณอย่างตรงไปตรงมาเกี่ยวกับทั้งสองด้านของการเปลี่ยนแปลงนี้

คุณจะต้องยอมละทิ้งการบันทึกอัตโนมัติ ไม่มีการใช้ keploy record ในการเฝ้าดูทราฟฟิกจริง ไม่มีการจำลองการพึ่งพาที่ได้มาจากการรัน production ไม่มีเวทมนตร์ของ eBPF ที่ไม่ต้องการโค้ดเลย หากความสามารถนั้นมีความสำคัญต่อคุณ ให้เก็บ Keploy ไว้ในกล่องเครื่องมือสำหรับงานนั้น เครื่องมือทั้งสองสามารถทำงานร่วมกันได้

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

หากคุณกำลังชั่งน้ำหนักเครื่องมือทั้งสองอย่างเทียบกัน การเปรียบเทียบ Apidog vs Keploy จะอธิบายคุณสมบัติแต่ละอย่างโดยละเอียด และหาก Keploy ไม่เหมาะสมกับทีมของคุณโดยเฉพาะ บทสรุปทางเลือกที่ดีที่สุดสำหรับ Keploy ก็คุ้มค่าที่จะพิจารณา

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

Apidog สามารถนำเข้าการบันทึกของ Keploy ที่มีอยู่ของฉันได้หรือไม่? ไม่ได้โดยตรง การบันทึกของ Keploy เป็นการบันทึกขณะรันไทม์ และ Apidog ทำงานจาก API specs วิธีปฏิบัติคือการบันทึก API surface ของคุณเป็น OpenAPI (หรือ Postman/cURL) แล้วนำเข้าสิ่งนั้น ใช้การบันทึกของ Keploy ของคุณเป็นรายการตรวจสอบว่าควรครอบคลุมเอนด์พอยต์ใดบ้าง

Apidog บันทึกทราฟฟิกสดและจำลองฐานข้อมูลของฉันโดยอัตโนมัติเหมือน Keploy หรือไม่? ไม่ Apidog ไม่ได้บันทึกทราฟฟิกผ่าน eBPF และไม่ได้สร้าง mock การพึ่งพาโดยอัตโนมัติจากการรันจริง นั่นคือจุดแข็งที่โดดเด่นของ Keploy Apidog สร้างการทดสอบและ mock จาก schema ของคุณ และคุณสร้างสถานการณ์เพิ่มเติมจากนั้น

อะไรที่มาแทนที่ keploy record และ keploy test? ไม่มีคำสั่งที่เทียบเท่า record แทนที่คุณจะนำเข้า spec, สร้างชุดเริ่มต้นด้วย AI, สร้างสถานการณ์, และรันพวกมันด้วย apidog run แทน keploy test

การใช้ความพยายามในการสร้างเพิ่มเติมเพื่อย้ายจาก Keploy คุ้มค่าหรือไม่? หากคุณต้องการการทดสอบที่อ่านง่าย, สามารถตรวจสอบได้ใน pull requests, และเป็นของทั้งทีม, ใช่ แต่ถ้าความต้องการหลักของคุณคือการบันทึกพฤติกรรมการรันไทม์จริงโดยไม่ต้องใช้ความพยายามใดๆ รวมถึง mock การพึ่งพา Keploy ยังคงทำได้ดีกว่า ดังนั้นควรเก็บมันไว้สำหรับงานนั้น

ฉันสามารถใช้เครื่องมือทั้งสองพร้อมกันได้หรือไม่? ได้ หลายทีมใช้ Keploy สำหรับการตรวจสอบ regression ที่อิงจากการบันทึก และใช้ Apidog สำหรับชุดทดสอบ end-to-end ที่ออกแบบมาอย่างดี, เอกสาร, และ mocks พวกมันแก้ปัญหาที่แตกต่างกัน

เริ่มต้นจากตรงไหน

เลือกหนึ่งบริการ ส่งออก OpenAPI spec ของบริการนั้น, นำเข้าสู่ Apidog, ให้ AI ร่างกรณีทดสอบบางส่วน, จากนั้นสร้างสถานการณ์จริงหนึ่งสถานการณ์พร้อมสภาพแวดล้อมและไฟล์ข้อมูลขนาดเล็ก รันด้วย apidog run และเชื่อมต่อเข้ากับ CI เมื่อวงจรนั้นใช้งานได้ดีแล้ว ให้ขยายออกไป คุณจะแลกเปลี่ยนความสะดวกสบายของการบันทึกกับการทดสอบที่ทั้งทีมของคุณสามารถอ่าน, เปลี่ยนแปลง, และไว้วางใจได้ หากต้องการเจาะลึกเกี่ยวกับ CLI เอง ให้เริ่มต้นด้วย คู่มือการติดตั้ง และ การทดสอบ REST API ผ่าน Command Line

ปุ่ม