บิลด์ของคุณเป็นสีเขียว (ผ่าน). การทดสอบ Unit test ผ่าน, JAR ถูกแพ็ก, artifact ถูกปรับใช้. จากนั้นคำขอจริงแรกส่งไปยัง API ของสภาพแวดล้อมทดสอบ (staging) และบริการปลายน้ำส่งคืนรหัส 500 เนื่องจากมีคนเปลี่ยนฟิลด์การตอบกลับเมื่อสองคอมมิตที่แล้ว. บิลด์แจ้งว่าทุกอย่างเรียบร้อยดี. แต่มันไม่เป็นเช่นนั้น. มันแค่ไม่เคยตรวจสอบ API เลย.
นี่คือช่องว่างที่ไปป์ไลน์ Bamboo CI ส่วนใหญ่มี. Atlassian Bamboo เก่งในการคอมไพล์โค้ด, รัน JUnit suites, และจัดส่ง artifacts. สิ่งที่มันไม่ได้ทำด้วยตัวเองคือการตรวจสอบว่า HTTP endpoint ของคุณยังคงทำงานตามที่สัญญาไว้หรือไม่. หากคุณต้องการตาข่ายนิรภัยนั้น คุณต้องเพิ่มการทดสอบ API แบบอัตโนมัติเป็นขั้นตอนหนึ่งในไปป์ไลน์. คู่มือนี้จะแนะนำวิธีการทำเช่นนั้นอย่างละเอียด โดยใช้ Apidog เพื่อสร้างการทดสอบและ Apidog CLI เพื่อรันการทดสอบเหล่านั้นภายในงาน (job) ของ Bamboo.
เมื่อจบบทความนี้ คุณจะมีแผน Bamboo ที่เมื่อมีการพุชแต่ละครั้ง จะทำการเรียก endpoint ของคุณ, ตรวจสอบรหัสสถานะ, ตรวจสอบความถูกต้องของเนื้อหาการตอบกลับเทียบกับ schema ของคุณ, และทำให้บิลด์ล้มเหลวทันทีที่สัญญา (contract) เสียหาย. ไม่ต้องมีสิทธิ์ใช้งาน Postman ต่อที่นั่ง, ไม่มีสคริปต์ assertion ที่เขียนด้วยมือให้ต้องดูแล, และมีรายงานผลการทดสอบ HTML ที่แท้จริงแนบไปกับทุกบิลด์. ดาวน์โหลด Apidog หากคุณต้องการทำตาม; ส่วนของ CLI นั้นฟรีและเปิดเผย.
button
ทำไมการทดสอบ API ควรสถิตอยู่ใน Bamboo ไม่ใช่หลังจากมัน
หลายทีมทดสอบ API ด้วยตนเอง หรือแย่กว่านั้นคือในสภาพแวดล้อมจริง (production). มีคนคลิกผ่านคอลเลกชันของคำขอที่บันทึกไว้ก่อนการเผยแพร่และเพ่งมองการตอบกลับ. วิธีนี้ใช้ได้จนกว่าจะใช้ไม่ได้. ผู้คนลืม. การเผยแพร่เกิดขึ้นในวันศุกร์. endpoint เดียวที่ไม่มีใครคิดจะตรวจสอบซ้ำคือ endpoint ที่พัง.
CI มีอยู่เพื่อกำจัดตัวแปรที่เป็นมนุษย์. จุดประสงค์ทั้งหมดของเซิร์ฟเวอร์บิลด์คือการตรวจสอบแบบเดียวกันทำงานในลักษณะเดียวกันทุกครั้ง, โดยอัตโนมัติ, โดยไม่ต้องมีใครจำได้ว่าจะต้องรันมัน. การทดสอบ unit test ของคุณอยู่ที่นั่นแล้ว. การทดสอบ integration test ของคุณก็น่าจะอยู่ที่นั่นด้วย. การทดสอบ API สมควรได้รับการปฏิบัติแบบเดียวกัน และด้วยเหตุผลที่ชัดเจนไม่กี่ประการ:
- สัญญา (Contracts) เสียหายอย่างเงียบๆ. นักพัฒนา backend เปลี่ยนชื่อฟิลด์ JSON จาก
userIdเป็นuser_id. Unit tests ยังคงผ่านเพราะมันทดสอบฟังก์ชัน ไม่ใช่รูปแบบข้อมูลที่ส่งผ่านสาย. ทีมโมบายล์พบในอีกสามวันต่อมา. การทดสอบ API ที่ยืนยันบนเนื้อหาการตอบกลับจะตรวจจับได้ในบิลด์เดียวกันที่นำเสนอการเปลี่ยนแปลงนั้น. - รหัสสถานะ (Status codes) โกหกเมื่อไม่มีใครดู. Endpoint ที่ควรจะคืนค่า
201 Createdเริ่มคืนค่า200 OKหลังจากมีการปรับโครงสร้าง. ใกล้เคียงกับการทำงานที่ถูกต้อง แต่ทางเทคนิคแล้วผิด และไคลเอนต์ที่เข้มงวดจะปฏิเสธมัน. การยืนยันในไปป์ไลน์จะแจ้งเตือนเรื่องนี้ในไม่กี่วินาที. - ปัญหาการถดถอยของการยืนยันตัวตน (Auth regressions) มีค่าใช้จ่ายสูง. การไหลของการรีเฟรชโทเค็นที่กำหนดค่าผิดพลาดที่คืนค่า
401สำหรับข้อมูลประจำตัวที่ถูกต้อง เป็นข้อบกพร่องที่ทำให้หน้าจอเข้าสู่ระบบล่มได้. การเรียกคำขอที่ผ่านการยืนยันตัวตนในทุกบิลด์หมายความว่าคุณพบปัญหาก่อนที่ผู้ใช้ของคุณจะเจอ. - สภาพแวดล้อมเปลี่ยนแปลง (Environments drift). สภาพแวดล้อมทดสอบ (Staging) มีการเปลี่ยนแปลงการกำหนดค่า, มีการพลิกสลับคุณสมบัติ (feature flag), มีการอัปเกรด dependency. การรันชุดการทดสอบ API ชุดเดียวกันกับสภาพแวดล้อมทดสอบหลังจากการปรับใช้แต่ละครั้ง จะบอกคุณทันทีว่าสภาพแวดล้อมยังคงทำงานได้ดีหรือไม่.
บริบทที่ลึกซึ้งกว่านั้นคือเหตุผลเดียวกันที่ทีมงานนำ CI/CD มาใช้ตั้งแต่แรก: ตรวจจับปัญหาตั้งแต่เนิ่นๆ, เมื่อยังแก้ไขได้ง่าย, แทนที่จะเป็นตอนสาย, เมื่อมันมีค่าใช้จ่ายสูงและน่าอับอาย. การทดสอบ API เป็นเพียงชั้นหนึ่งของกลยุทธ์นั้นที่ไปป์ไลน์ส่วนใหญ่ข้ามไป.
การทดสอบ API เข้ากับแผน Bamboo ได้อย่างไร
ก่อนที่จะลงรายละเอียดทีละขั้นตอน, เป็นประโยชน์ที่จะทำความเข้าใจว่าสิ่งนี้อยู่ในโมเดลของ Bamboo อย่างไร. Bamboo จัดระเบียบงานเป็นแผน (plans), และแต่ละแผนประกอบด้วยหนึ่งขั้นตอน (stages) ขึ้นไปที่ทำงานตามลำดับ. แต่ละขั้นตอนมีงาน (jobs), และแต่ละงานคือลำดับของงานย่อย (tasks). งานย่อยคือคำสั่งจริง: checkout, compile, รันสคริปต์.
การทดสอบ API ของคุณจะกลายเป็นงานย่อยภายในงาน ภายในขั้นตอน. ตำแหน่งที่เป็นธรรมชาติคือขั้นตอนเฉพาะที่ทำงานหลังจากแอปพลิเคชันของคุณถูกสร้างและปรับใช้กับสภาพแวดล้อมทดสอบ, เพราะคุณต้องการสิ่งที่ทำงานอยู่เพื่อส่งคำขอไป. แผนทั่วไปจะมีลักษณะดังนี้:
Plan: payments-service (แผน: บริการชำระเงิน)
├── Stage: Build (ขั้นตอน: บิลด์)
│ └── Job: Compile & Unit Test (งาน: คอมไพล์และทดสอบ Unit Test)
│ ├── Task: Source Code Checkout (งานย่อย: ตรวจสอบโค้ดต้นฉบับ)
│ └── Task: Maven, clean package (งานย่อย: Maven, แพ็กเกจใหม่)
├── Stage: Deploy to Staging (ขั้นตอน: ปรับใช้ไปยังสภาพแวดล้อมทดสอบ)
│ └── Job: Deploy (งาน: ปรับใช้)
│ └── Task: Deploy artifact to staging (งานย่อย: ปรับใช้ artifact ไปยังสภาพแวดล้อมทดสอบ)
└── Stage: API Tests <- นี่คือสิ่งที่คุณกำลังเพิ่ม
└── Job: Run API Suite (งาน: รันชุดทดสอบ API)
├── Task: Source Code Checkout (งานย่อย: ตรวจสอบโค้ดต้นฉบับ)
├── Task: Script, install & run Apidog CLI (งานย่อย: สคริปต์, ติดตั้งและรัน Apidog CLI)
└── Task: Final, publish test report (งานย่อย: สุดท้าย, เผยแพร่รายงานผลการทดสอบ)
หากงานย่อยในขั้นตอน API Tests ออกด้วยรหัสที่ไม่ใช่ศูนย์, Bamboo จะตั้งค่าสถานะขั้นตอนว่าล้มเหลวและทำให้บิลด์ทั้งหมดเป็นสีแดง. นั่นคือพฤติกรรมที่คุณต้องการ; สัญญาที่เสียหายควรหยุดสายการผลิต ไม่ใช่เล็ดรอดไปได้.
เครื่องมือที่ทำงานจริงในงานสคริปต์นั้นคือ Apidog CLI, เป็นตัวรันบรรทัดคำสั่งที่ดำเนินการสถานการณ์การทดสอบที่คุณออกแบบด้วยภาพใน Apidog. คุณสร้างการทดสอบครั้งเดียว, ใน GUI, โดยไม่มีโค้ด, และการทดสอบเดียวกันจะทำงานโดยไม่มีการเปลี่ยนแปลงทั้งในเทอร์มินัลของคุณและใน Bamboo. นี่คือรูปแบบเดียวกันกับที่ทีมใช้ในการ ทำให้การทดสอบ API เป็นอัตโนมัติในระบบ CI/CD ใดๆ; Bamboo เป็นหนึ่งในเป้าหมายหลายๆ อย่าง.
ขั้นตอนที่ 1: สร้างการทดสอบ API ของคุณใน Apidog
คุณไม่สามารถรันการทดสอบใน CI ได้จนกว่าคุณจะมีชุดทดสอบ. Apidog คือที่ที่คุณออกแบบมัน, และการออกแบบนั้นเป็นแบบภาพ, ดังนั้นวิศวกร QA ที่ไม่เขียนโค้ดก็สามารถสร้างชุดทดสอบเดียวกันกับที่นักพัฒนา backend จะสร้างได้.
เปิด Apidog และสร้างสถานการณ์การทดสอบ (test scenario). สถานการณ์คือลำดับของคำขอ API ที่จัดเรียงไว้, รันจากบนลงล่าง, โดยแต่ละขั้นตอนสามารถนำข้อมูลจากขั้นตอนก่อนหน้ามาใช้ซ้ำได้. สถานการณ์ที่สมจริงสำหรับบริการชำระเงินอาจเป็น:
POST /auth/loginพร้อมข้อมูลรับรองที่ถูกต้อง, จากนั้นแยก bearer token จากการตอบกลับ.POST /ordersโดยใช้โทเค็นนั้น, สร้างคำสั่งซื้อใหม่, จากนั้นบันทึกorderIdที่ได้รับคืน.GET /orders/{orderId}และยืนยันว่าคำสั่งซื้อปรากฏขึ้นพร้อมสถานะที่ถูกต้อง.DELETE /orders/{orderId}เพื่อล้างข้อมูล.
สำหรับแต่ละคำขอ, เพิ่มการยืนยัน (assertions). นี่คือส่วนที่เปลี่ยนคำขอให้เป็นการทดสอบ. Apidog ช่วยให้คุณยืนยันด้วยภาพได้, ไม่ต้องเขียนสคริปต์:
- รหัสสถานะเท่ากับ
200(หรือ201, แล้วแต่สัญญาจะระบุ). - ฟิลด์ JSON มีอยู่และตรงกัน:
$.data.statusเท่ากับ"pending". - การตอบกลับตรวจสอบความถูกต้องกับ OpenAPI schema ของ endpoint, ดังนั้นประเภทฟิลด์ที่ไม่คาดคิดหรือคุณสมบัติที่จำเป็นหายไปจะทำให้ขั้นตอนล้มเหลว.
- เวลาตอบสนองยังคงต่ำกว่าเกณฑ์, เช่น 800ms, ดังนั้นการถดถอยที่ช้าเกินไปก็จะปรากฏขึ้นด้วย.
การยืนยันตาม Schema นั้นมีคุณค่าที่ควรกล่าวถึง. เนื่องจาก Apidog เป็นแบบ "schema-first", มันจึงรู้รูปร่างที่ endpoint ของคุณได้สัญญาไว้ใน API definition แล้ว. คุณสามารถยืนยัน "การตอบกลับนี้ตรงกับ schema" ได้ด้วยการคลิกเพียงครั้งเดียว, และการตรวจสอบเพียงครั้งเดียวนั้นจะป้องกันปัญหาการเปลี่ยนแปลงสัญญา (contract drift), ฟิลด์ที่เปลี่ยนชื่อ, ประเภทที่ไม่ถูกต้อง, คุณสมบัติที่หายไป, ทั้งหมดนี้โดยที่คุณไม่ต้องเขียนโค้ดแม้แต่บรรทัดเดียว. หากคุณมาจากเครื่องมือที่เน้นสคริปต์, แค่สิ่งนี้ก็ช่วยลดภาระการบำรุงรักษาได้มากแล้ว. นี่คือโมเดลการยืนยันด้วยภาพแบบเดียวกับที่ทำให้ Apidog เป็น ทางเลือก Postman ยอดนิยมสำหรับการทดสอบ API.
จัดกลุ่มสถานการณ์ที่เกี่ยวข้องเข้าด้วยกันเป็นชุดทดสอบ (test suite) หากคุณมีหลายชุด. ชุดทดสอบเป็นเพียงชุดรวมของสถานการณ์ที่คุณสามารถรันพร้อมกันได้, ซึ่งทำให้คำสั่ง CI ของคุณง่ายขึ้น; คุณชี้ตัวรันไปที่ชุดทดสอบเดียวแทนที่จะต้องระบุสถานการณ์ยี่สิบสถานการณ์.
ใช้ตัวแปรสภาพแวดล้อม (environment variables) สำหรับสิ่งใดก็ตามที่เปลี่ยนแปลงระหว่างสภาพแวดล้อม local, staging, และ production: base URL, ข้อมูลรับรอง, คีย์ API. กำหนดสภาพแวดล้อม staging ใน Apidog โดยตั้งค่า baseUrl ไปยังโฮสต์ staging ของคุณ. คุณจะบอก CLI ว่าจะใช้สภาพแวดล้อมใดเมื่อรัน, ดังนั้นสถานการณ์เดียวกันจะทำงานกับ staging ใน Bamboo และกับ localhost บนแล็ปท็อปของคุณ.
ขั้นตอนที่ 2: สร้าง Apidog Access Token และจด ID
Bamboo ทำงานแบบ headless บน build agent. มันไม่สามารถล็อกอินเข้าบัญชี Apidog ของคุณผ่านเบราว์เซอร์ได้, ดังนั้น CLI จึงยืนยันตัวตนด้วย access token แทน.
ภายในสถานการณ์การทดสอบของคุณ, เปิดแท็บ CI/CD. คลิก Add access token, จากนั้น Generate token. คัดลอกค่าไปเก็บไว้ในที่ปลอดภัยชั่วขณะ; คุณจะเก็บมันเป็นตัวแปร Bamboo ในไม่ช้า, ไม่ใช่การวางมันลงในสคริปต์. โทเค็นคือสิ่งที่ทำให้ build agent สามารถดึงและรันการทดสอบของโปรเจกต์ส่วนตัวของคุณได้.
ในขณะที่คุณอยู่ในแท็บ CI/CD นั้น, Apidog จะสร้างคำสั่งรันแบบเต็มให้คุณ. เลือก Command line เป็นผู้ให้บริการและมันจะแสดงผลสิ่งที่คุณสามารถคัดลอกได้โดยตรง, โดยมี ID สถานการณ์การทดสอบและ ID โปรเจกต์ของคุณที่กรอกไว้แล้ว. คำสั่งที่คัดลอกมานั้นคือรากฐานของงาน Bamboo ของคุณ. ส่วนที่คุณสนใจ:
- Access token: การยืนยันตัวตน, ส่งผ่านเป็น
--access-token. - Test scenario ID: ID ตัวเลขหลัง
-t, ระบุว่าจะรันสถานการณ์ใด. - Environment ID: ID ตัวเลขหลัง
-e, บอก CLI ให้รันกับสภาพแวดล้อม staging.
เก็บคำสั่งที่สร้างขึ้นนั้นไว้ให้พร้อมใช้. ขั้นตอนถัดไปจะปรับใช้สำหรับ Bamboo.
ขั้นตอนที่ 3: เก็บโทเค็นเป็นตัวแปรแผน Bamboo
ห้ามฮาร์ดโค้ด (hard-code) โทเค็นลงในงานสคริปต์. ใครก็ตามที่มีสิทธิ์อ่านแผน และใครก็ตามที่อ่านบันทึกบิลด์ จะเห็นมัน.
ใน Bamboo, ไปที่แผนของคุณ, เปิด Plan Configuration, และหาแท็บ Variables. เพิ่มตัวแปรใหม่. ตั้งชื่อให้ชัดเจน เช่น APIDOG_ACCESS_TOKEN และวางโทเค็นเป็นค่า. Bamboo จะปิดบังตัวแปรที่มีชื่อว่า password, secret, หรือ token, ดังนั้นตั้งชื่อให้เหมาะสมและค่าจะถูกซ่อนไว้ในบันทึกและ UI.
เมื่อรัน Bamboo จะเปิดเผยตัวแปรแผนให้กับสคริปต์เป็นตัวแปรสภาพแวดล้อม, โดยมีคำนำหน้าและตัวพิมพ์ใหญ่, และจุดจะกลายเป็นเครื่องหมายขีดล่าง. ตัวแปรชื่อ APIDOG_ACCESS_TOKEN จะใช้งานได้ในงาน shell ของคุณในรูปแบบ $bamboo_APIDOG_ACCESS_TOKEN. คุณจะอ้างอิงถึงสิ่งนั้น, ไม่ใช่โทเค็นดิบ, ในสคริปต์บิลด์.
สุขอนามัยเดียวกันนี้ใช้กับความลับอื่นๆ ที่การทดสอบของคุณต้องการ; รหัสผ่านฐานข้อมูล, คีย์ API ของบุคคลที่สาม, signing secret. กำหนดให้เป็นตัวแปร Bamboo ที่ถูกปิดบัง และอ่านผ่านคำนำหน้าสภาพแวดล้อม bamboo_.
ขั้นตอนที่ 4: เพิ่มขั้นตอนการทดสอบ API และงานสคริปต์
ตอนนี้มาเชื่อมต่อเข้ากับแผน. ใน Plan Configuration, เพิ่มขั้นตอนใหม่และตั้งชื่อว่า API Tests. เพิ่มงาน (job) ให้กับมัน, จากนั้นเพิ่มงานย่อย (tasks) ให้กับงานตามลำดับนี้.
งานย่อยที่ 1, Source Code Checkout (ตรวจสอบโค้ดต้นฉบับ). แม้ว่าการทดสอบจะอยู่ในคลาวด์ของ Apidog, การตรวจสอบ repo ของคุณทำให้ agent มีไดเรกทอรีการทำงานที่สะอาดและช่วยให้คุณสามารถคอมมิตไฟล์ข้อมูลในเครื่องใดๆ (เช่น ข้อมูลการวนซ้ำ CSV) พร้อมกับโค้ดของคุณ.
งานย่อยที่ 2, Script (สคริปต์). นี่คือหัวใจสำคัญ. เลือกงานย่อย Script, ตั้งค่า interpreter เป็น Shell (หรือ /bin/sh), และใช้ inline script body. สคริปต์จะติดตั้ง Apidog CLI บน agent และรันสถานการณ์ของคุณ.
Apidog CLI เป็นแพ็กเกจ npm, ดังนั้น agent ต้องมี Node.js v16 หรือใหม่กว่า. หาก agent ของคุณมี Node อยู่แล้ว, คุณสามารถข้ามบรรทัดการติดตั้งได้; หากไม่มี, จัดเตรียมผ่านความสามารถของ Bamboo หรือ agent ที่ใช้ Docker. นี่คือเนื้อหาสคริปต์แบบเต็ม:
#!/bin/sh
set -e
# Install the Apidog CLI globally on the agent (ติดตั้ง Apidog CLI ทั่วโลกบน agent)
npm install -g apidog-cli
# Run the test scenario against staging, output an HTML + CLI report (รันสถานการณ์การทดสอบกับสภาพแวดล้อม staging, แสดงผลรายงาน HTML + CLI)
apidog run \
--access-token "$bamboo_APIDOG_ACCESS_TOKEN" \
-t 637132 \
-e 358171 \
-r cli,html \
--out-dir ./apidog-reports
เปลี่ยน 637132 เป็น ID สถานการณ์การทดสอบจริงของคุณ และ 358171 เป็น ID สภาพแวดล้อม staging ของคุณ, ซึ่งเป็นค่าที่ Apidog สร้างขึ้นในขั้นตอนที่ 2. ข้อสังเกตบางประการเกี่ยวกับสิ่งที่แต่ละ flag ทำ:
--access-tokenอ่านตัวแปร Bamboo ที่ถูกปิดบัง, ดังนั้นความลับจึงไม่ปรากฏในสคริปต์.-t(ตัวย่อของ--test-scenario) เลือกสถานการณ์ที่จะรัน. หากต้องการรันทั้งชุดทดสอบแทน, ใช้--test-suite <id>; หากต้องการรันโฟลเดอร์สถานการณ์ทั้งหมด, ใช้-f <folderId>.-e(--environment) เลือกสภาพแวดล้อม staging ที่คุณกำหนดใน Apidog, ดังนั้นคำขอจะส่งไปยังโฮสต์ที่ถูกต้องพร้อมตัวแปรที่ถูกต้อง.-r cli,html(--reporters) สร้างรายงานทั้งแบบคอนโซลที่คุณจะเห็นในบันทึกบิลด์ของ Bamboo และรายงาน HTML ที่คุณสามารถเผยแพร่เป็น artifact ได้. CLI ยังรองรับรูปแบบjsonและjunitที่นี่.--out-dirควบคุมตำแหน่งที่รายงานจะถูกบันทึก. ค่าเริ่มต้นคือ./apidog-reports; การตั้งค่าอย่างชัดเจนทำให้พาธ artifact สามารถคาดเดาได้.
set -e ที่ด้านบนมีความสำคัญ. มันทำให้ shell ออกเมื่อคำสั่งแรกที่ล้มเหลว. Apidog CLI ส่งคืนรหัสออกที่ไม่ใช่ศูนย์อยู่แล้วเมื่อมีการยืนยันใดๆ ล้มเหลว, และรหัสที่ไม่ใช่ศูนย์นั้นคือสิ่งที่บอก Bamboo ให้บิลด์ล้มเหลว. ทั้งสองอย่างนี้รับประกันว่าสัญญา API ที่เสียหายจะทำให้บิลด์เป็นสีแดง แทนที่จะถูกฝังอยู่ในบันทึก.
หากคุณเคยเชื่อมต่อการทดสอบ API เข้ากับ GitHub Actions มาก่อน, สิ่งนี้จะรู้สึกคุ้นเคย; ตัวรันและ flags เหมือนกัน, ต่างกันแค่เพียง wrapper ของ YAML เทียบกับ Bamboo UI.
ขั้นตอนที่ 5: เผยแพร่รายงานผลการทดสอบเป็น Bamboo Artifact
บิลด์สีแดงบอกคุณว่ามีบางอย่างเสีย. รายงาน HTML บอกคุณว่า อะไร เสีย. เชื่อมต่อมันเพื่อให้ทุกบิลด์เก็บรายงานไว้.
ในงานเดียวกัน, ไปที่แท็บ Artifacts และกำหนด shared artifact ใหม่:
- ชื่อ:
Apidog Test Report - ตำแหน่ง:
apidog-reports - รูปแบบการคัดลอก:
**/*
หลังจากแต่ละบิลด์, Bamboo จะรวบรวมทุกอย่างในไดเรกทอรี apidog-reports และแนบไปกับผลลัพธ์ของบิลด์. เปิดบิลด์ใดก็ได้, ไปที่แท็บ Artifacts, และคุณสามารถดาวน์โหลดหรือดูรายงาน HTML ได้; ผลลัพธ์ทีละคำขอ, การยืนยันที่รันไปแล้ว, และเนื้อหาการตอบกลับที่แน่นอนสำหรับสิ่งที่ล้มเหลว. ส่วนสุดท้ายนั้นช่วยประหยัดเวลาในการดีบักได้จริง. แทนที่จะรันคำขอที่ล้มเหลวด้วยตนเองซ้ำ, คุณสามารถอ่านการตอบกลับที่ถูกจับภาพได้โดยตรงจากบิลด์.
สำหรับการแสดงผลที่สมบูรณ์ยิ่งขึ้นภายใน Bamboo, reporter แบบ junit ก็มีประโยชน์เช่นกัน. เพิ่ม junit ลงในรายการ -r, จากนั้นเพิ่มงานย่อย JUnit Parser ที่ชี้ไปยังไฟล์ JUnit XML. Bamboo จะแสดงจำนวนการทดสอบ, การแบ่งแยกผ่าน/ล้มเหลว, และแนวโน้มความล้มเหลวโดยตรงบนสรุปบิลด์, ในลักษณะเดียวกับที่แสดงผลลัพธ์การทดสอบ unit test ของคุณ.
ขั้นตอนที่ 6: รันและอ่านผลลัพธ์
เรียกใช้แผนด้วยตนเองสำหรับการรันครั้งแรก; ใน Bamboo, รันแผนจากหน้าแผน. ดูบันทึกบิลด์สำหรับขั้นตอน API Tests. คุณจะเห็น npm ติดตั้ง CLI, จากนั้นเอาต์พุตการรัน Apidog ไหลไปเรื่อยๆ, ชื่อสถานการณ์, แต่ละคำขอ, แต่ละการยืนยัน, และบรรทัดสรุปสุดท้ายพร้อมผลรวม.
ผลลัพธ์สองอย่าง:
การยืนยันทั้งหมดผ่าน. CLI ออกด้วยรหัส 0, ขั้นตอนเป็นสีเขียว, บิลด์สำเร็จ, และรายงาน HTML ยังคงถูกแนบเป็น artifact อยู่ดี, เพื่อให้คุณมีบันทึก. ดีมาก. ตอนนี้ทำให้เป็นอัตโนมัติ; ตั้งค่าแผนให้เรียกใช้เมื่อมีการคอมมิตไปยังสาขาหลักของคุณ (Plan Configuration, Triggers, Repository polling หรือ webhook). จากนี้ไป, ทุกการพุชจะรันชุดทดสอบ API ของคุณโดยไม่มีการแทรกแซงจากมนุษย์.
การยืนยันล้มเหลว. CLI ออกด้วยรหัสที่ไม่ใช่ศูนย์, set -e หยุดสคริปต์, ขั้นตอนเป็นสีแดง, และบิลด์ล้มเหลว. เปิด artifact, ค้นหาคำขอที่ล้มเหลว, และอ่านการตอบกลับที่ถูกจับภาพไว้. อาจมีฟิลด์เปลี่ยนไป. อาจเป็นไปได้ว่าสภาพแวดล้อม staging คืนค่า 502 เพราะ dependency หยุดทำงาน. ไม่ว่าจะด้วยวิธีใดคุณจะทราบภายในหนึ่งหรือสองนาทีของการคอมมิตที่ทำให้เกิดปัญหานั้น, ซึ่งเป็นผลตอบแทนทั้งหมด.
สรุปผลคอนโซลที่สมจริงจะมีลักษณะดังนี้:
┌──────────────┬──────────┬──────────┐
│ │ executed │ failed │
├──────────────┼──────────┼──────────┤
│ iterations │ 1 │ 0 │
├──────────────┼──────────┼──────────┤
│ requests │ 4 │ 0 │
├──────────────┼──────────┼──────────┤
│ assertions │ 11 │ 1 │
└──────────────┴──────────┴──────────┘
1 assertion failed: (1 การยืนยันล้มเหลว:)
GET /orders/{orderId}
expected $.data.status to equal "pending" but got "failed" (คาดหวังให้ $.data.status เท่ากับ "pending" แต่ได้ "failed")
การยืนยันที่ล้มเหลวเพียงหนึ่งเดียวนั้นคือเหตุผลทั้งหมดที่ขั้นตอนนั้นมีอยู่. มันตรวจจับการถดถอยของสัญญาที่คอมไพล์ได้สะอาดและผ่านการทดสอบ unit test ทุกรายการ.
การทำให้ชุดทดสอบเชื่อถือได้ใน CI
การทดสอบ API ที่ไม่เสถียร (flaky) แย่กว่าไม่มีการทดสอบเลย, เพราะมันฝึกให้ทีมเพิกเฉยต่อบิลด์สีแดง. นิสัยบางอย่างช่วยให้ชุดทดสอบน่าเชื่อถือ.
แยกข้อมูลการทดสอบ. การรันแต่ละครั้งควรสร้างสิ่งที่จำเป็นและล้างข้อมูลหลังการทำงาน, เช่นการสร้างแล้วลบคำสั่งซื้อข้างต้น. การทดสอบที่ขึ้นอยู่กับบันทึกที่ใครบางคนสร้างเมื่อวันอังคารที่แล้วจะพังทันทีที่บันทึกนั้นเปลี่ยนแปลง. รันกับสภาพแวดล้อม staging หรือ test โดยเฉพาะ, ห้ามรันกับ production.
ใช้การรันที่ขับเคลื่อนด้วยข้อมูล (data-driven runs) เพื่อครอบคลุมโดยไม่มีการซ้ำซ้อน. หากคุณต้องการทดสอบ endpoint เดียวกันด้วยอินพุตยี่สิบแบบ, อย่าสร้างยี่สิบสถานการณ์. ใช้สถานการณ์เดียวกับ --iteration-data path/to/data.csv (หรือ -d), และ CLI จะรันครั้งละหนึ่งแถว. คอมมิตไฟล์ CSV ไปยัง repo ของคุณเพื่อให้ถูก checkout พร้อมกับโค้ด. นี่คือ รูปแบบการทดสอบที่ขับเคลื่อนด้วยข้อมูล แบบเดียวกับที่คุณจะใช้ในเครื่อง, เพียงแค่ขับเคลื่อนจากไฟล์ใน CI.
ปักหมุดเวอร์ชัน CLI. npm install -g apidog-cli จะดึงเวอร์ชันล่าสุด. สำหรับบิลด์ที่สร้างซ้ำได้, ให้ปักหมุดเวอร์ชันที่ทราบ, npm install -g apidog-cli@<version>, เพื่อให้การอัปเดต CLI ไม่เปลี่ยนแปลงพฤติกรรมโดยไม่บอกกล่าวระหว่างสองบิลด์ของคอมมิตเดียวกัน.
ตั้งค่าการหมดเวลาที่เหมาะสม (sensible timeouts). เพิ่ม --timeout-request 10000 เพื่อให้ล้มเหลวอย่างรวดเร็วใน endpoint ที่ค้างแทนที่จะปล่อยให้บิลด์ค้างจนกว่า timeout ของ Bamboo ของตัวเองจะฆ่ามัน. ข้อความ "request timed out" ที่ชัดเจนดีกว่าบิลด์ที่ค้างอย่างคลุมเครือ.
ควบคุมการปรับใช้ที่ขั้นตอน API. เนื่องจากการทดสอบ API ทำงานก่อนขั้นตอนการปรับใช้ production ใดๆ, และขั้นตอนที่ล้มเหลวจะหยุดแผน, สัญญาที่เสียหายจึงไม่สามารถไปถึง production ได้. ลำดับนั้นคือประตูปล่อย (release gate) ของคุณ. มันเป็นเวอร์ชันที่ใช้งานได้จริงของ การสร้างไปป์ไลน์ CI/CD ที่แท้จริง แทนที่จะเป็นบิลด์ที่แค่คอมไพล์.
รักษาสถานการณ์ให้เร็วและเน้นเป้าหมาย. ชุดทดสอบ CI ที่ใช้เวลาถึงยี่สิบนาทีจะไม่ถูกรันทุกครั้งที่คอมมิต; ผู้คนจะย้ายไปรันตอนกลางคืนและสูญเสียการตอบกลับที่รวดเร็ว. เก็บชุดทดสอบต่อคอมมิตไว้ที่เส้นทางที่สำคัญของคุณ, การยืนยันตัวตน, CRUD หลัก, การไหลของการชำระเงิน, และรันชุดทดสอบกรณีขอบที่ละเอียดถี่ถ้วนตามกำหนดเวลา.
สรุป
Bamboo ปกป้องคุณจากโค้ดที่ไม่สามารถคอมไพล์ได้และการทดสอบ unit test ที่ไม่ผ่านอยู่แล้ว. การเพิ่มขั้นตอนการทดสอบ API ช่วยขยายการป้องกันนั้นไปยังสัญญาที่บริการของคุณเปิดเผยผ่านเครือข่ายจริงๆ, ซึ่งเป็นชั้นที่เหตุการณ์ "แต่มันใช้งานได้บนเครื่อง" ส่วนใหญ่เกิดขึ้นจริง.
การตั้งค่าใช้เวลาไม่นาน: สร้างการทดสอบแบบภาพที่เข้าใจ schema ใน Apidog, สร้าง access token, เก็บไว้เป็นตัวแปร Bamboo ที่ถูกปิดบัง, และเพิ่มงานสคริปต์ที่รัน apidog run ด้วย ID สถานการณ์และสภาพแวดล้อมของคุณ. เผยแพร่รายงานเป็น artifact, ตั้งค่าประตูการปรับใช้ของคุณหลังจากการทดสอบนี้, และเรียกใช้แผนเมื่อมีการคอมมิตแต่ละครั้ง. หลังจากนั้นทุกอย่างจะเป็นไปโดยอัตโนมัติ. ทุกการพุชจะตรวจสอบ API ของคุณ, และสัญญาที่เสียหายจะทำให้บิลด์เป็นสีแดงก่อนที่จะกลายเป็นการหยุดชะงัก.
ดาวน์โหลด Apidog และสร้างสถานการณ์การทดสอบแรกของคุณ, จากนั้นวางคำสั่ง CLI ที่สร้างขึ้นลงในงานสคริปต์ Bamboo. ครั้งแรกที่มันตรวจจับการถดถอยที่คอมไพล์ได้สะอาด, ขั้นตอนนี้จะคุ้มค่ากับสิบนาทีที่ใช้ในการตั้งค่า.
button