การทดสอบถดถอย API: ตรวจจับ Breaking Changes ตั้งแต่เนิ่นๆ

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

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

ปุ่ม

การทดสอบถดถอย API คืออะไร (และทำไม API ถึงถดถอย)

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

API ถดถอยด้วยเหตุผลธรรมดาๆ ใครบางคนเปลี่ยนชื่อฟิลด์ JSON การปรับโครงสร้างโค้ดทำให้ 200 กลายเป็น 204 กฎการตรวจสอบใหม่ปฏิเสธอินพุตที่เคยยอมรับ การอัปเกรด ORM เปลี่ยนการจัดรูปแบบวันที่โดยไม่แจ้งให้ทราบ การอัปเดตเวอร์ชันของไลบรารีเปลี่ยนแปลงข้อความแสดงข้อผิดพลาดที่ไคลเอนต์ทำการแยกวิเคราะห์ ไม่มีสิ่งใดที่แสดงเป็นข้อผิดพลาดในการคอมไพล์ สิ่งเหล่านี้จะแสดงเป็นอินทิเกรชันที่เสีย และบ่อยครั้งที่เกิดกับผู้เรียกใช้เพียงบางส่วนเท่านั้น

ความแตกต่างที่สำคัญในที่นี้คือ: การทดสอบถดถอย API นั้นแคบกว่าการทดสอบถดถอยซอฟต์แวร์ทั่วไป คุณไม่ได้ตรวจสอบตรรกะทางธุรกิจซ้ำทั่วทั้งแอป คุณกำลังตรวจสอบว่าส่วนติดต่อ HTTP ซึ่งเป็นส่วนที่ระบบอื่นเชื่อมต่อด้วย ไม่ได้มีการเปลี่ยนแปลง การมุ่งเน้นเช่นนี้ทำให้การเรียกใช้ในการคอมมิตแต่ละครั้งมีค่าใช้จ่ายต่ำ

สิ่งที่ควรใช้เป็นเกณฑ์พื้นฐาน

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

กำหนดเกณฑ์พื้นฐานสี่ชั้นนี้:

รหัสสถานะ ทุกปลายทางควรคืนรหัสสถานะที่ทราบสำหรับอินพุตที่ทราบ 200 ที่กลายเป็น 500 หรือ 201 ที่กลายเป็น 200 ถือเป็นการถดถอยแม้ว่าเนื้อหาจะดูปกติดีก็ตาม
โครงสร้างการตอบสนอง โครงสร้างและชนิดของข้อมูลในการตอบสนอง ชื่อฟิลด์ การซ้อน และไม่ว่าค่าจะเป็นสตริง ตัวเลข อาร์เรย์ หรือออบเจกต์ การเปลี่ยนแปลงโครงสร้างข้อมูลเป็นข้อผิดพลาดที่เงียบและพบบ่อยที่สุด
ค่าฟิลด์สำคัญ ไม่ใช่ทุกค่า แต่เป็นค่าที่มีความหมายตามสัญญา: id ที่ต้องมีอยู่, status enum ที่ต้องอยู่ในชุดที่กำหนด, total ที่ต้องเป็นตัวเลข
สัญญา ความสัมพันธ์ระหว่างข้อกำหนด OpenAPI ของคุณและการตอบสนองแบบสด หากข้อกำหนดระบุว่า email เป็นสิ่งที่ต้องระบุ และ API หยุดส่งคืนข้อมูลนั้น นั่นคือการละเมิดสัญญา ดู การทดสอบสัญญา API สำหรับวิธีทำให้ข้อกำหนดเป็นแหล่งความจริง

กฎที่เป็นประโยชน์: ยืนยันในสิ่งที่ไคลเอนต์จะล้มเหลว ไม่ใช่สิ่งที่บังเอิญอยู่ในเพย์โหลดวันนี้ Timestamp ของ createdAt เปลี่ยนแปลงทุกคำขอ ดังนั้นให้กำหนดชนิดและรูปแบบ ไม่ใช่ค่า

นี่คือชุดการยืนยันขั้นต่ำสำหรับปลายทางเดียว ซึ่งเขียนเป็นรายการตรวจสอบที่คุณจะใช้กับผลตอบสนอง:

GET /v1/users/42 -> 200
  body.id            มีอยู่, ชนิดตัวเลข
  body.email         มีอยู่, ชนิดสตริง, ตรงตามรูปแบบอีเมล
  body.status        เป็นหนึ่งใน ["active", "pending", "suspended"]
  body.roles         ชนิดอาร์เรย์
  response time      < 800 ms

ห้าบรรทัดนี้อธิบายถึงสัญญา หากข้อใดข้อหนึ่งล้มเหลวหลังจากการเปลี่ยนแปลง คุณก็เกิดการถดถอย สำหรับการศึกษาเชิงลึกเกี่ยวกับการเขียนการตรวจสอบกับเนื้อหาการตอบสนอง โปรดดู การยืนยัน API

การทดสอบถดถอยแบบ Manual vs. แบบอัตโนมัติ

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

การทดสอบถดถอยอัตโนมัติจะนำมนุษย์ออกจากกระบวนการ คุณบันทึกชุดทดสอบเพียงครั้งเดียว จากนั้นเครื่องจะเรียกใช้ซ้ำทุกครั้งที่มีการพุช ทุกครั้งที่มีการสร้าง Pull Request และทุกครั้งที่มีการดีพลอย คุณค่าที่ได้ไม่ใช่ความเร็วในการรันครั้งเดียว แต่คือการที่ชุดทดสอบทำงานทุกครั้ง โดยไม่มีใครต้องตัดสินใจว่าคุ้มค่ากับความพยายามหรือไม่

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

	Manual	Automated
รันทุกครั้งที่มีการเปลี่ยนแปลง	ไม่, ขึ้นอยู่กับวินัย	ใช่, โดยค่าเริ่มต้น
ขอบเขตการครอบคลุม	ปลายทางไม่กี่จุด	ทั้งชุดทดสอบ
ค่าใช้จ่ายต่อการรัน	นาทีของเวลาคน	วินาทีของการประมวลผล
ตรวจจับการผิดพลาดเวลาตี 2	ไม่	ใช่
ความพยายามเบื้องต้น	ต่ำ	ปานกลาง

สำหรับโปรเจกต์ที่มากกว่าแค่โปรเจกต์ทดลอง ควรทำให้เป็นอัตโนมัติ

การสร้างชุดทดสอบถดถอยที่นำกลับมาใช้ใหม่ได้

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

จัดโครงสร้างชุดการทดสอบเพื่อให้ทนทานต่อการเปลี่ยนแปลง:

จัดกลุ่มตามทรัพยากร ไม่ใช่ตามฟีเจอร์ รวบรวมการทดสอบ /users ทั้งหมดไว้ด้วยกัน การทดสอบ /orders ทั้งหมดไว้ด้วยกัน เมื่อคุณแก้ไขบริการผู้ใช้ คุณจะรู้ว่าต้องดูที่กลุ่มใด

ใช้ตัวแปรสภาพแวดล้อมสำหรับสิ่งที่เปลี่ยนแปลงได้ URL พื้นฐาน, โทเค็นการยืนยันตัวตน, และ ID ผู้เช่า ควรอยู่ในสภาพแวดล้อม ไม่ใช่ฮาร์ดโค้ดในแต่ละคำขอ สิ่งนี้ช่วยให้ชุดการทดสอบเดียวกันสามารถรันได้ทั้งในสภาพแวดล้อม Local, Staging และ Production เพียงแค่เปลี่ยนการตั้งค่าเดียว

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

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

นี่คือตัวอย่างตารางข้อมูลสำหรับการทดสอบการตรวจสอบเดียวที่อาจมีลักษณะเป็น CSV:

email,expectedStatus
alice@example.com,201
bob@test.co,201
not-an-email,422
,422
a@b,422

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

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

การเรียกใช้ชุดการทดสอบทุกครั้งที่มีการเปลี่ยนแปลงใน CI

ชุดการทดสอบถดถอยที่อยู่บนแล็ปท็อปของคุณจะปกป้องแค่แล็ปท็อปของคุณเท่านั้น จุดประสงค์คือการรันในระบบ Continuous Integration (CI) ในเหตุการณ์เดียวกันที่สามารถทำให้เกิดการถดถอยได้: Pull Request และการรวมโค้ดเข้าสู่สาขาหลักของคุณ

รูปแบบนี้เหมือนกันในทุกระบบ CI ติดตั้งตัวรันแบบ Headless ชี้ไปที่ชุดการทดสอบที่คุณบันทึกไว้ และทำให้ Build ล้มเหลวหากมีการยืนยันใดๆ ล้มเหลว Apidog มีตัวรันแบบ Command-line สำหรับสิ่งนี้โดยเฉพาะ ติดตั้งด้วย Node:

npm install -g apidog-cli

จากนั้นเรียกใช้สถานการณ์การทดสอบหรือชุดการทดสอบที่บันทึกไว้ด้วย ID โดยกำหนดเป้าหมายไปยังสภาพแวดล้อมที่เลือก และสร้างรายงาน:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t 123456 \
  -e 789012 \
  -r cli,html,junit

วิเคราะห์ดังนี้:

--access-token ใช้เพื่อยืนยันตัวตนในการรัน จัดเก็บโทเค็นเป็นความลับของ CI ไม่ใช่ใน Repository
-t คือ ID ของสถานการณ์ โฟลเดอร์ หรือชุดการทดสอบที่จะรัน
-e คือ ID ของสภาพแวดล้อม เพื่อให้ชุดการทดสอบเดียวกันสามารถกำหนดเป้าหมายเป็น staging หรือ production ได้โดยการเปลี่ยนค่าเดียว
-r แสดงรายการรูปแบบรายงาน cli จะพิมพ์ลงในคอนโซล html จะสร้างรายงานที่อ่านง่าย และ junit จะสร้าง XML ที่ CI ของคุณสามารถแยกวิเคราะห์เพื่อแสดงผลผ่าน/ไม่ผ่านต่อการทดสอบ

ตัวรันเป็นแบบ Headless มันเข้ากันได้กับทุกขั้นตอน CI ที่สามารถรัน Node ได้ ดังนั้นคำสั่งเดียวกันนี้จึงทำงานได้ใน GitHub Actions, GitLab CI, Jenkins หรือ CircleCI นี่คืองาน GitHub Actions ที่รันชุดทดสอบทุกครั้งที่มี Pull Request:

name: API Regression
on: [pull_request]
jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: '22'
      - run: npm install -g apidog-cli
      - run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 123456 \
            -e 789012 \
            -r cli,junit
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

เมื่อสถานการณ์ล้มเหลว ตัวรันจะออกด้วยรหัสที่ไม่ใช่ศูนย์และงานจะแสดงเป็นสีแดง Pull Request จะถูกบล็อกจนกว่าจะมีคนตรวจสอบ สำหรับ Pipeline ที่พร้อมใช้งานแบบ Copy-Paste และรูปแบบ CI เพิ่มเติม ดู Apidog CLI สำหรับ CI/CD และ วิธีทำให้การทดสอบ API เป็นอัตโนมัติใน GitHub Actions

หากคุณป้อนไฟล์ข้อมูลให้ชุดทดสอบ ให้ส่งด้วย -d:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t 123456 \
  -e 789012 \
  -d ./test-data/emails.csv \
  -r cli,junit

กำลังทดสอบ Branch ของฟีเจอร์ที่มี API เวอร์ชันของตัวเองอยู่ใช่ไหม เพิ่ม --branch เพื่อรันกับชุดทดสอบที่บันทึกไว้ของ Branch นั้นแทนที่จะเป็นค่าเริ่มต้น หากต้องการเก็บประวัติการรันใน Cloud ให้เพิ่มแฟล็ก --upload-report แบบเปล่าๆ

การเปรียบเทียบ Schema และ Contract (Diffing)

การยืนยันจะตรวจจับการถดถอยในพฤติกรรม การเปรียบเทียบ Schema จะตรวจจับในคำจำกัดความ ซึ่งมักจะก่อนที่คุณจะดีพลอย

แนวคิด: ข้อกำหนด OpenAPI ของคุณเป็นไฟล์ที่มีเวอร์ชันใน repo ของคุณ เมื่อมีคนแก้ไข คุณจะเปรียบเทียบข้อกำหนดใหม่กับข้อกำหนดก่อนหน้า และจัดประเภทการเปลี่ยนแปลง การเพิ่มฟิลด์ที่ไม่บังคับนั้นปลอดภัย การลบฟิลด์ การเปลี่ยนชื่อ การทำให้ชนิดข้อมูลเข้มงวดขึ้น หรือการทำให้ฟิลด์ที่ไม่บังคับกลายเป็นสิ่งที่จำเป็น เป็นการเปลี่ยนแปลงที่ก่อให้เกิดข้อผิดพลาด เครื่องมือเปรียบเทียบสามารถระบุการเปลี่ยนแปลงที่ก่อให้เกิดข้อผิดพลาดใน Pull Request เพื่อให้ผู้ตรวจสอบเห็น "สิ่งนี้ลบ user.phone ออกไป" แทนที่จะเป็นกำแพงของ YAML

จับคู่สิ่งนั้นกับการทดสอบสัญญา (contract testing) กับ API ที่ใช้งานจริง ในแต่ละครั้งที่รัน ให้ตรวจสอบการตอบสนองจริงเทียบกับ schema ปัจจุบัน หากข้อกำหนดสัญญาว่าจะมีฟิลด์ที่ API ไม่คืนค่าแล้ว หรือ API คืนค่าชนิดข้อมูลที่ข้อกำหนดห้ามไว้ การตรวจสอบก็จะล้มเหลว นี่คือการป้องกันสองทาง: การเปรียบเทียบ schema จะตรวจจับการแก้ไขสัญญาโดยตั้งใจ และการทดสอบสัญญาจะตรวจจับโค้ดที่เริ่มออกนอกเส้นทางจากสัญญา

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

Apidog รันชุดทดสอบถดถอยอย่างไร

Apidog ครอบคลุมส่วนต่างๆ ที่อธิบายไว้ข้างต้นในที่เดียว ซึ่งทำให้ชุดทดสอบและข้อกำหนดอยู่เคียงข้างกัน

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

สำหรับกรณีที่ขับเคลื่อนด้วยข้อมูล ให้แนบชุดข้อมูล CSV หรือ JSON เข้ากับสถานการณ์ แล้ว Apidog จะรันหนึ่งกรณีต่อหนึ่งแถว บันทึกสถานการณ์ที่เกี่ยวข้องไว้ในชุดทดสอบเพื่อให้การรันครั้งเดียวครอบคลุมทรัพยากรหรือกระบวนการทำงานทั้งหมด

ตัวรัน apidog-cli นำชุดทดสอบที่บันทึกไว้เหล่านั้นไปรันแบบ Headless ใน CI ดังที่แสดงไว้ข้างต้น มันรันสถานการณ์และชุดทดสอบที่บันทึกไว้ มันไม่ใช่โปรแกรมส่งคำขอแบบโต้ตอบและไม่ใช่ตัวสร้างโหลด มันทำหน้าที่เดียว: เล่นชุดทดสอบถดถอยของคุณซ้ำและรายงานผลที่ผ่าน ขอบเขตที่แคบนี้เองที่ทำให้มันสามารถเข้ากับขั้นตอน CI ที่รองรับ Node ได้ สำหรับ CLI พร้อมเวิร์กโฟลว์แบบสคริปต์ โปรดดู คู่มือ Apidog CLI CI/CD Pipeline

เวิร์กโฟลว์เริ่มต้น

นี่คือลำดับขั้นตอนที่คุณสามารถนำไปใช้ได้ภายในสัปดาห์นี้ โดยไม่ต้องสร้างกลยุทธ์การทดสอบของคุณใหม่:

เลือกห้าปลายทางที่คุณมีการเรียกใช้บ่อยที่สุด ความเสี่ยงการถดถอยจะกระจุกตัวอยู่ในจุดที่มีการรับส่งข้อมูลมากที่สุด เริ่มจากตรงนั้น
บันทึกคำขอสำหรับแต่ละปลายทางพร้อมกับการยืนยัน รหัสสถานะ โครงสร้างการตอบสนอง และฟิลด์สำคัญสองหรือสามฟิลด์สำหรับแต่ละรายการ นี่คือเกณฑ์พื้นฐานของคุณ
เพิ่มโฟลว์แบบต่อเนื่องหนึ่งรายการ สร้าง อ่าน อัปเดต ลบ บนทรัพยากรหลักของคุณ วิธีนี้จะตรวจจับการถดถอยข้ามคำขอที่การทดสอบแบบแยกเดี่ยวพลาดไป
เพิ่มตารางข้อมูลสำหรับปลายทางที่มีการตรวจสอบเข้มข้นหนึ่งรายการ ใส่อินพุตที่ถูกต้อง ว่างเปล่า และไม่ถูกต้องจำนวนเล็กน้อย
เชื่อมโยงเข้ากับ CI ใน Pull Request ติดตั้ง apidog-cli, รันชุดทดสอบด้วย -r junit, และบล็อกการรวมโค้ดหากเกิดความล้มเหลว
ขยายชุดทดสอบเมื่อมีข้อผิดพลาดหลุดรอดไป การถดถอยที่เกิดขึ้นจริงในการผลิตทุกครั้งที่หลุดรอดไป จะกลายเป็นกรณีทดสอบใหม่ ชุดทดสอบจะแข็งแกร่งขึ้นจากความผิดพลาดของมันเอง

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

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

การทดสอบถดถอย API แตกต่างจากการทดสอบถดถอยทั่วไปอย่างไร? การทดสอบถดถอยทั่วไปจะตรวจสอบพฤติกรรมของแอปพลิเคชันทั่วทั้งระบบอีกครั้ง รวมถึง UI และตรรกะทางธุรกิจ การทดสอบถดถอย API จะจำกัดขอบเขตไปที่ส่วนติดต่อ HTTP: เส้นทาง รหัสสถานะ โครงสร้างการตอบสนอง และค่าฟิลด์สำคัญ การมุ่งเน้นที่แคบช่วยให้รวดเร็วพอที่จะรันได้ทุกครั้งที่มีการคอมมิต และมันกำหนดเป้าหมายเฉพาะสิ่งที่ระบบอื่นเชื่อมโยงด้วย

ฉันควรรันชุดทดสอบถดถอยบ่อยแค่ไหน? ทุกครั้งที่มีการเปลี่ยนแปลงที่อาจส่งผลต่อ API ในทางปฏิบัติ หมายถึงทุก Pull Request และทุกการรวมโค้ดเข้าสู่สาขาหลักของคุณ ซึ่งรันโดยอัตโนมัติใน CI รักษาชุดทดสอบหลักที่รวดเร็วสำหรับ Pull Request และการรันแบบ end-to-end ขนาดใหญ่ขึ้นสำหรับการ Build ตอนกลางคืน เพื่อให้การตรวจสอบต่อการคอมมิตยังคงรวดเร็ว

ฉันควรยืนยันอะไรเพื่อหลีกเลี่ยงชุดทดสอบที่ไม่เสถียร? ยืนยันในสิ่งที่ผู้ใช้จะล้มเหลว กำหนดรหัสสถานะ โครงสร้างและการป้อนข้อมูลของการตอบสนอง และค่าของฟิลด์ที่มีความหมายตามสัญญา เช่น ID และสถานะ Enums สำหรับค่าที่เปลี่ยนแปลงทุกคำขอ เช่น Timestamp ให้ยืนยันชนิดและรูปแบบ ไม่ใช่ค่าตรงๆ การยืนยันมากเกินไปในข้อมูลที่มีความผันผวนเป็นสาเหตุหลักของความล้มเหลวที่ผิดพลาด

ฉันสามารถรันการทดสอบถดถอย API ได้โดยไม่ต้องเขียนโค้ดหรือไม่? ได้ เครื่องมืออย่าง Apidog ช่วยให้คุณสร้างสถานการณ์และการยืนยันด้วยภาพ จากนั้นรันแบบ Headless ใน CI ด้วย apidog-cli คุณบันทึกชุดทดสอบเพียงครั้งเดียวผ่านอินเทอร์เฟซ และตัวรัน Command-line จะเล่นซ้ำใน Pipeline ของคุณ ดังนั้นการทดสอบจะรันโดยอัตโนมัติโดยไม่ต้องมี Test Harness ที่เขียนด้วยมือ

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