วิธีเพิ่ม Test Automation ใน DevOps Pipeline ของคุณ

การปรับใช้ (deploy) ถูกปล่อยออกไปในเวลา 16.00 น. ของวันศุกร์ การทดสอบยูนิตผ่านหมด คอนเทนเนอร์ถูกสร้างขึ้น การเปิดตัวเป็นไปอย่างราบรื่นไม่มีข้อผิดพลาด จากนั้นคิวสนับสนุนเริ่มเต็ม: การชำระเงิน (checkout) ส่งคืนข้อผิดพลาด 500 บั๊กนี้ไม่เคยอยู่ในโค้ดที่ผ่านการทดสอบ แต่มันอยู่ในวิธีการที่สองบริการสื่อสารกัน และไม่มีการทดสอบใด ๆ ใน pipeline ที่ครอบคลุมการสื่อสารนั้นเลย

นี่คือช่องว่างที่การทดสอบอัตโนมัติใน DevOps ควรจะเข้ามาแก้ไข และส่วนที่ทีมส่วนใหญ่ลงทุนน้อยเกินไปคือ API layer การทดสอบยูนิตพิสูจน์ว่าฟังก์ชันทำงานได้แยกต่างหาก การทดสอบ UI แบบ end-to-end พิสูจน์ว่าเบราว์เซอร์สามารถคลิกผ่าน flow ได้ ช้าและไม่เสถียร สัญญา (contract) ระหว่างบริการของคุณ ซึ่งเป็นสิ่งที่มักจะพังใน production นั้นอยู่ตรงกลางและมักไม่ได้รับการตรวจสอบ การทดสอบ API อยู่ตรงนั้นพอดี

การทดสอบอัตโนมัติใน DevOps หมายถึงอะไรกันแน่

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

หลักการเบื้องหลังคือ shift-left: เลื่อนการทดสอบให้เร็วขึ้น เข้าใกล้ช่วงเวลาที่นักพัฒนาเขียนการเปลี่ยนแปลง บั๊กที่ถูกตรวจพบบน pull request ใช้เวลาแก้ไขเพียงไม่กี่นาที บั๊กเดียวกันที่ถูกตรวจพบใน production มีค่าใช้จ่ายในการ rollback, การเปิดช่องทางแจ้งเหตุการณ์ และการวิเคราะห์หลังเกิดเหตุ (postmortem) ระบบอัตโนมัติคือสิ่งที่ทำให้การ shift-left เป็นไปได้ เพราะมนุษย์ไม่สามารถรันชุดการทดสอบการถดถอย (regression suite) ด้วยตนเองทุกครั้งที่ commit ได้ แต่ pipeline สามารถทำได้

ข้อผิดพลาดคือการมองว่า "การทดสอบอัตโนมัติ" เป็นสิ่งเดียว พีระมิดการทดสอบจะแบ่งออกเป็นชั้น ๆ และแต่ละชั้นจะตอบคำถามที่แตกต่างกัน:

• Unit tests ถามว่าฟังก์ชันเดียวส่งคืนค่าที่ถูกต้องหรือไม่ การทดสอบเหล่านี้รวดเร็วและมีจำนวนมาก
• API and integration tests ถามว่าบริการของคุณสร้างการตอบสนองที่ถูกต้องและสื่อสารกันอย่างถูกต้องหรือไม่ การทดสอบเหล่านี้มีจำนวนน้อยกว่า แต่แต่ละการทดสอบครอบคลุมพื้นที่ได้มากขึ้น
• End-to-end tests ถามว่าระบบทั้งหมดทำงานได้จากมุมมองของผู้ใช้หรือไม่ การทดสอบเหล่านี้ช้า เปราะบาง และควรมีจำนวนน้อย

การทดสอบ API อยู่ตรงกลางที่มีประสิทธิภาพ ทำงานได้ในไม่กี่วินาที ไม่ใช่หลายนาที ไม่ขึ้นอยู่กับ UI ที่แสดงผล ดังนั้นจึงไม่พังเมื่อปุ่มเคลื่อนที่ และทดสอบพื้นผิวที่บริการอื่น ๆ ของคุณและลูกค้าของคุณพึ่งพาอยู่จริง นั่นคือเหตุผลว่าทำไมใน DevOps pipeline การทดสอบ API จึงรับภาระการตรวจจับการถดถอย (regression) ได้มากกว่า layer อื่น ๆ สำหรับพื้นฐานของการปฏิบัตินั้น การทดสอบ API แบบอัตโนมัติ ครอบคลุมถึงสิ่งที่จะยืนยันและเหตุผลก่อนที่คุณจะกังวลว่าจะรันที่ใด

วงจรชีวิต DevOps ทีละขั้นตอน และตำแหน่งของการทดสอบ API

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

ในระหว่างการพัฒนา: local และ pre-commit

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

ในทางปฏิบัติ นี่คือ scenario เดียวกันกับที่คุณจะรันใน CI เพียงแต่ชี้ไปที่สภาพแวดล้อม local คุณสร้างมันครั้งเดียว หากคุณไม่เคยสร้างมาก่อน วิธีเขียน test scenarios ด้วย Apidog จะอธิบายขั้นตอนการเชื่อมโยง request และดึงค่าจาก response หนึ่งไปยังอีก response หนึ่ง

บน pull requests: ประตูการรวมโค้ด

นี่คือตำแหน่งที่มีมูลค่าสูงสุดสำหรับการทดสอบ API และเป็นจุดที่ทีมมักจะข้ามไป เมื่อมีการเปิด pull request pipeline จะเริ่มทำงานบริการ รัน API scenarios ของคุณกับบริการนั้น และรายงานผลว่าผ่านหรือไม่ผ่านเป็นสถานะการตรวจสอบ การตรวจสอบที่ไม่ผ่านจะบล็อกการรวมโค้ด (merge)

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

หลังการสร้าง ก่อนการเปิดตัว: การตรวจสอบการรวมระบบและสัญญา

เมื่อ artifact ถูกสร้างและปรับใช้ไปยังสภาพแวดล้อม staging หรือ integration แล้ว ให้รันชุดการทดสอบที่กว้างขึ้น นี่คือจุดที่คุณทดสอบการเชื่อมต่อที่แท้จริง: บริการชำระเงินยังคงยอมรับ request body ของบริการสั่งซื้อหรือไม่ การแบ่งหน้า (pagination) ยังคงส่งคืนฟิลด์ที่ไคลเอนต์ของคุณอ่านหรือไม่ auth token ที่ออกโดยบริการหนึ่งถูกบริการอื่นยอมรับหรือไม่

ขั้นตอนนี้ยังเป็นจุดที่การคิดแบบสัญญา (contract thinking) ให้ผลตอบแทน การเปลี่ยนแปลงที่ถูกต้องในระดับ local อาจยังคงทำให้ consumer ปลายน้ำพังได้ การรันชุด scenarios ทั้งหมดกับสภาพแวดล้อมที่รวมระบบเข้าด้วยกันจะตรวจจับการพังทลายระหว่างบริการที่ unit tests ไม่สามารถมองเห็นได้ตามโครงสร้าง รูปแบบเหล่านี้สืบทอดมาจากการปฏิบัติการทดสอบ API แบบอัตโนมัติที่กว้างขึ้น

เมื่อถึงเวลา deploy: smoke tests

การ deploy ไม่ได้เสร็จสิ้นเมื่อการเปิดตัวเสร็จสมบูรณ์ แต่จะเสร็จสิ้นเมื่อคุณมีหลักฐานว่าเวอร์ชันใหม่สามารถให้บริการทราฟฟิกได้อย่างถูกต้อง smoke test คือ scenario ขนาดเล็กและรวดเร็วที่ทดสอบเส้นทางสำคัญทันทีหลังการ deploy: ผู้ใช้สามารถยืนยันตัวตนได้หรือไม่ พวกเขาสามารถอ่านข้อมูลของตนได้หรือไม่ endpoint ที่สำคัญต่อสุขภาพ (health-critical) ส่งคืน 200 พร้อมรูปแบบที่ถูกต้องหรือไม่

รักษาชุดการทดสอบนี้ให้เล็กและรวดเร็ว หน้าที่ของมันคือสัญญาณไปต่อหรือไม่ไปต่อ ไม่ใช่การครอบคลุมทั้งหมด หากล้มเหลว คุณจะทำการ rollback โดยอัตโนมัติ รัน scenario เดียวกันกับสภาพแวดล้อม production โดยการสลับ environment flag เพียงอันเดียว ไม่ต้องดูแลการทดสอบซ้ำซ้อน

ใน production: การตรวจสอบอย่างต่อเนื่อง

หลังการ deploy วงจรยังไม่หยุด scenarios API เดียวกันกับที่คุณรันใน CI สามารถรันตามกำหนดเวลาใน production เป็นการตรวจสอบสังเคราะห์ (synthetic monitoring) เพื่อตรวจจับ third-party dependency ที่เสื่อมสภาพหรือใบรับรองที่หมดอายุก่อนที่ลูกค้าจะพบเห็น เส้นแบ่งระหว่างการทดสอบและการตรวจสอบส่วนใหญ่ขึ้นอยู่กับตารางเวลาที่รัน การตรวจสอบ API ครอบคลุมการเปลี่ยนการทดสอบที่ผ่านให้เป็นระบบเตือนภัยล่วงหน้าของ production

กฎง่าย ๆ ที่มีประโยชน์ตลอดทั้งห้าขั้นตอน: ยิ่งใกล้ production มากเท่าไหร่ ชุดการทดสอบก็ยิ่งเล็กลงและเร็วขึ้นเท่านั้น การครอบคลุมที่กว้างบน PRs และในการรวมระบบ; ชุด smoke test ที่บางเบาและเด็ดขาดในขั้นตอน deploy และในการตรวจสอบ

ทำไม API layer จึงมีบทบาทสำคัญใน pipeline

ควรจะมีความชัดเจนว่าทำไมการทดสอบ API จึงสมควรได้รับความสำคัญมากกว่าการเพิ่มภาระให้กับการทดสอบ UI

พวกมันรวดเร็ว API scenario สื่อสารโดยตรงผ่าน HTTP ไม่ต้องเปิดเบราว์เซอร์ ไม่ต้องรอ DOM ไม่ต้องกลัว headless Chrome จะไม่เสถียรกับการเรนเดอร์ที่ช้า scenario ที่ทดสอบ endpoint นับสิบรายการจะเสร็จสิ้นในไม่กี่วินาที ซึ่งช่วยให้คุณรันมันได้ทุกครั้งที่ commit โดยที่ผู้คนไม่ต้องเรียนรู้ที่จะเพิกเฉยต่องานที่ใช้เวลาสิบนาที

พวกมันเสถียร UI tests จะพังเมื่อชื่อ class เปลี่ยนไปหรือเมื่อ element เรนเดอร์เฟรมช้า API tests จะพังก็ต่อเมื่อ contract จริง ๆ มีการเปลี่ยนแปลง ซึ่งเป็นเวลาที่คุณต้องการทราบพอดี ความไม่เสถียรน้อยลงหมายความว่าผู้คนจะเชื่อถือ build ที่ไม่ผ่าน และ build ที่ผู้คนเชื่อถือได้เท่านั้นที่จะสามารถเป็นเกทได้

พวกมันทดสอบสิ่งที่รวมเข้าด้วยกัน แอปมือถือของคุณ, การรวมระบบกับพาร์ทเนอร์, microservices ของคุณเอง ล้วนขึ้นอยู่กับ API contract ไม่ใช่ CSS ของคุณ เมื่อ contract นั้นเปลี่ยนแปลงไปอย่างเงียบ ๆ ผู้ใช้งานทุกรายจะพังพร้อมกัน การทดสอบ API คือ layer ที่ตรวจจับสิ่งนี้ได้

นี่คือเหตุผลว่าทำไมคำถามเกี่ยวกับ pipeline จึงเป็นคำถามเกี่ยวกับ API อย่างแท้จริง คุณสามารถมีชุด unit test ที่ละเอียดถี่ถ้วนและชุด UI test ที่สวยงาม แต่ก็ยังอาจปล่อยบั๊กการชำระเงินในบ่ายวันศุกร์ออกไปได้ เพราะไม่มี layer ใดเฝ้าดูรอยต่อที่บริการต่าง ๆ มาบรรจบกัน

การเชื่อมต่อการทดสอบ API เข้ากับ pipeline ด้วย Apidog CLI

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

ด้วย Apidog คุณไม่จำเป็นต้องเขียนการทดสอบใหม่เป็นโค้ด คุณสร้าง scenario เพียงครั้งเดียวในแอป จากนั้น Apidog CLI จะรัน scenario เดียวกันนั้นแบบ headless CLI เป็นแพ็คเกจ npm ดังนั้น CI runner ใด ๆ ที่มี Node.js สามารถใช้งานได้

npm install -g apidog-cli

จากนั้นรัน scenario คุณสร้าง access token และค้นหา scenario และ environment IDs ภายในแท็บ CI/CD ของ test scenario ใน Apidog ซึ่งจะสร้างคำสั่งเต็มให้คุณคัดลอก:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 \
  -e 1629989 \
  -r cli

มีหลายสิ่งหลายอย่างที่กำลังทำงานจริงที่นี่ แฟล็ก `-t` ใช้ระบุชื่อ scenario ด้วย ID; สลับเป็น `-f` เพื่อรันทั้งโฟลเดอร์ หรือ `--test-suite` เพื่อรัน test suite ที่จัดเตรียมไว้เป็นงานเดียว แฟล็ก `-e` เลือก environment ซึ่งเป็นวิธีที่ scenario เดียวกันนี้ใช้เป็นเกทสำหรับ PR กับ staging และ smoke-test กับ production โดยไม่ต้องสร้างชุดทดสอบซ้ำ แฟล็ก `-r` เลือก reporters; `cli` จะพิมพ์ออกสู่ log และ `junit` จะส่งออก XML ที่แดชบอร์ด CI ของคุณสามารถแสดงผลเป็นรายงานการทดสอบได้

ส่วนที่ทำให้มันเป็นเกทคือ exit code เมื่อการยืนยันทุกอย่างผ่าน `apidog run` จะคืนค่า `0` เมื่อมีสิ่งใดล้มเหลว มันจะคืนค่าที่ไม่ใช่ศูนย์ ระบบ CI ของคุณจะอ่านโค้ดนั้น ทำเครื่องหมายว่าขั้นตอนล้มเหลว และบล็อกการ merge หรือการ deploy คุณไม่จำเป็นต้องกำหนดค่าเกทแยกต่างหาก; exit code คือเกท ลองรัน `apidog run --help` เพื่อดูแฟล็กทั้งหมดสำหรับเวอร์ชันของคุณ

นี่คือขั้นตอน PR-gate ที่เชื่อมต่อเข้ากับ GitHub Actions:

name: API Tests
on: [pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run API scenarios
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r cli,junit

token จะถูกเก็บไว้ใน repository secrets และเข้าถึงขั้นตอนผ่าน `env:` โดยไม่เคย hard-coded โค้ดบล็อกเดียวกันนี้สามารถใช้ได้กับ GitLab CI, Jenkins, CircleCI หรือ Azure Pipelines ด้วยไวยากรณ์เฉพาะของแพลตฟอร์มนั้น ๆ เพราะ dependency จริง ๆ เพียงอย่างเดียวคือ Node คำแนะนำเฉพาะแพลตฟอร์มจะครอบคลุมรายละเอียด: การทำให้การทดสอบ API เป็นไปโดยอัตโนมัติใน GitHub Actions และ การรวมการทดสอบ Apidog เข้ากับ Jenkins

สำหรับขั้นตอน smoke test ในช่วง deploy คำสั่งแทบไม่เปลี่ยนแปลง คุณแค่ชี้ไปที่ production environment ID และรักษา scenario ให้มีขนาดเล็ก:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e $PROD_ENV_ID -r cli

หนึ่ง scenario, การสลับ environment หนึ่งครั้ง, สองงาน นั่นคือเสน่ห์ทั้งหมดของการสร้างการทดสอบเพียงครั้งเดียวและรันตลอดวงจรชีวิต

ข้อผิดพลาดทั่วไปที่ทำให้เกทล้มเหลวอย่างเงียบ ๆ

pipeline อาจดูเหมือนเป็นระบบอัตโนมัติเต็มรูปแบบแต่ก็ยังไม่สามารถตรวจจับอะไรได้ โปรดระวังสิ่งเหล่านี้

• กลืนกิน exit code. บางคนใช้ shell pipeline ครอบคำสั่งทดสอบ หรือเพิ่ม `|| true` เพื่อ "หยุดไม่ให้ build พัง" นั่นก็เป็นการหยุดไม่ให้มันตรวจจับอะไรได้เช่นกัน Build จะเป็นสีเขียวตลอดไป อย่าปิดบัง non-zero exit ของ runner; exit นั้นคือจุดประสงค์ทั้งหมด
• ทดสอบเฉพาะ happy path. scenario ที่ยืนยัน `200 OK` แล้วหยุดอยู่แค่นั้น จะพลาดการพังทลายที่สำคัญไป ยืนยันรูปแบบ response body, ชนิดของฟิลด์, และ error responses สำหรับอินพุตที่ไม่ถูกต้อง API assertions ครอบคลุมการตรวจสอบที่มากกว่าแค่ status code
• งาน pre-deploy ขนาดใหญ่เพียงงานเดียว. การยัดการทดสอบทุกอย่างลงในขั้นตอนเดียวทันทีก่อนการเปิดตัวจะทำลายหลักการ shift-left คุณจะพบข้อผิดพลาดของ contract เพียงไม่กี่นาทีก่อนการส่งมอบ แทนที่จะพบใน PR กระจายชุดการทดสอบไปตามขั้นตอนต่าง ๆ: กว้างขวางใน PRs, บางเบาในขั้นตอน deploy
• การทดสอบกับ shared mutable environment. เมื่อ pipeline สองชุดทำงานกับฐานข้อมูลเดียวกัน การเขียนของ run หนึ่งจะส่งผลกระทบต่อการอ่านของอีก run หนึ่ง และคุณจะพบกับความล้มเหลวที่ไม่เสถียรที่บั่นทอนความน่าเชื่อถือ ใช้สภาพแวดล้อมที่แยกต่างหาก หรือใช้ การจำลอง API (API mocking) เพื่อจำลอง dependencies ที่คุณควบคุมไม่ได้ เพื่อไม่ให้การหยุดทำงานของ third party ทำให้ build ของคุณไม่ผ่าน
• ลืมรายงานเมื่อล้มเหลว. หากรายงานของคุณถูกอัปโหลดเมื่อการทดสอบผ่านเท่านั้น คุณจะไม่มีทางเห็นรายงานในเวลาที่คุณต้องการเลย กำหนดค่าการอัปโหลด artifact ให้ทำงานแม้ในกรณีที่ล้มเหลว

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

ควรจะรัน API tests ในขั้นตอนใดของ DevOps pipeline?

อย่างน้อยที่สุด ควรจะรันบน pull requests เป็น merge gate เนื่องจากสามารถตรวจจับข้อบกพร่องได้มากที่สุดด้วยต้นทุนที่ต่ำที่สุด ในอุดมคติก็ควรรันหลังการสร้าง (build) กับสภาพแวดล้อมที่รวมระบบเข้าด้วยกันเพื่อตรวจสอบ contract และเป็น smoke suite ขนาดเล็กทันทีหลังการ deploy scenarios ของ Apidog เดียวกันจะรันในแต่ละขั้นตอน; คุณเพียงแค่เปลี่ยน environment flag ทีมที่ใช้ Apidog โดยไม่ใช้ Postman ก็ทำตามขั้นตอนเดียวกันนี้

ความแตกต่างระหว่างการทดสอบ API แบบอัตโนมัติและ CI/CD คืออะไร?

CI/CD คือ pipeline ที่สร้าง, ทดสอบ และส่งมอบโค้ดของคุณโดยอัตโนมัติ การทดสอบ API แบบอัตโนมัติคือการทดสอบประเภทหนึ่งที่ทำงานภายใน pipeline นั้น CI/CD คือสายพานลำเลียง; การทดสอบ API แบบอัตโนมัติคือสถานีควบคุมคุณภาพบนสายพานนั้น หากคำว่า CI/CD เองยังไม่ชัดเจน CI/CD คืออะไร ครอบคลุมพื้นฐานต่าง ๆ

ฉันจำเป็นต้องเขียนการทดสอบ API ใหม่เป็นโค้ดเพื่อรันใน CI หรือไม่?

ไม่จำเป็นด้วย Apidog คุณสร้าง test scenario ด้วยภาพในแอป และ Apidog CLI จะรัน scenario เดียวกันนั้นแบบ headless CLI เป็นแพ็คเกจ npm ดังนั้น CI runner ใด ๆ ที่ติดตั้ง Node.js สามารถรันได้ด้วยคำสั่งเดียว

API tests ทำให้ build ล้มเหลวได้อย่างไร?

ผ่านทาง exit code เมื่อการยืนยันทุกอย่างใน scenario ผ่าน runner จะคืนค่า `0` เมื่อมีการยืนยันใด ๆ ล้มเหลว จะคืนค่าที่ไม่ใช่ศูนย์ ระบบ CI จะอ่านโค้ดนั้น ทำเครื่องหมายว่าขั้นตอนล้มเหลว และบล็อกการ merge หรือ deploy ไม่จำเป็นต้องมีการกำหนดค่าเกทแยกต่างหาก

การทดสอบประสิทธิภาพควรรันใน pipeline เดียวกันหรือไม่?

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

จะวาง API test ตัวแรกของคุณไว้ที่ไหน

การทดสอบอัตโนมัติใน DevOps ไม่ใช่เกทเดียวที่คุณสร้างเพียงครั้งเดียว มันคือการทดสอบ API ที่วางไว้อย่างรอบคอบตลอดวงจร: บนเครื่องของนักพัฒนาเพื่อการตอบกลับที่รวดเร็ว, บน pull request เพื่อเป็น merge gate ที่ตรวจจับข้อผิดพลาดได้มากที่สุด, หลังการ build เพื่อตรวจสอบ contract, ในช่วง deploy เป็น smoke signal และใน production เป็น monitor API layer ได้รับพื้นที่ส่วนใหญ่ใน pipeline เพราะมันรวดเร็ว เสถียร และทดสอบรอยต่อที่ระบบมักจะพังจริง ๆ

หากการทดสอบ API ของคุณยังคงเป็นขั้นตอนที่ต้องคลิกและรันด้วยมือ ช่องว่างที่ต้องปิดคือ merge gate ดาวน์โหลด Apidog สร้าง scenario หนึ่งรายการ คัดลอกคำสั่ง `apidog run` จากแท็บ CI/CD ของมัน แล้ววางบล็อก GitHub Actions ด้านบน คุณจะมีการทดสอบ API ที่บล็อกการ merge ที่เสียได้ภายในสิ้นวันนั้น และบั๊กที่เกิดจากการ deploy วันศุกร์จะปรากฏเป็นสีแดงบน pull request แทนที่จะไปอยู่ในคิวสนับสนุนของคุณ