API ของคุณผ่านการทดสอบทุกอย่างบนแล็ปท็อปของคุณ จากนั้นเพื่อนร่วมทีมก็ผสานสาขาที่เปลี่ยนชื่อฟิลด์ และไม่มีใครสังเกตเห็นจนกว่าไคลเอนต์บนมือถือจะเริ่มหยุดทำงานในการผลิต การทดสอบด้วยตนเองพลาดไปเพราะไม่มีใครรันชุดทดสอบซ้ำ นี่คือช่องว่างที่ Continuous Integration ถูกสร้างขึ้นมาเพื่อปิด และ TeamCity เป็นหนึ่งในเครื่องมือที่แข็งแกร่งที่สุดในการปิดช่องว่างนี้
TeamCity ซึ่งเป็นเซิร์ฟเวอร์ CI/CD ของ JetBrains จะรันไปป์ไลน์การบิลด์ของคุณทุกครั้งที่โค้ดถูกอัปโหลด สามารถคอมไพล์, ทดสอบ, แพ็คเกจ และปรับใช้ได้โดยไม่ต้องมีใครคลิกปุ่ม ส่วนที่ทีมมักจะข้ามคือการเชื่อมต่อการทดสอบ API จริงเข้ากับไปป์ไลน์นั้น พวกเขาจะทดสอบยูนิต, ทดสอบการคอมไพล์ของบิลด์ และปล่อย API โดยอาศัยความเชื่อมั่น ฟิลด์ที่ถูกเปลี่ยนชื่อ, ข้อผิดพลาด 500 ในกรณีเฉพาะ, กระบวนการยืนยันตัวตนที่เสีย; ไม่มีสิ่งใดสิ่งหนึ่งเหล่านี้จะปรากฏขึ้นจนกว่ามนุษย์จะเรียกใช้ปลายทางนั้น
คู่มือนี้จะอธิบายการเรียกใช้การทดสอบ API แบบอัตโนมัติภายใน TeamCity ตั้งแต่ต้นจนจบ คุณจะออกแบบและตรวจสอบการทดสอบของคุณใน Apidog จากนั้นเรียกใช้แบบ Headless ผ่าน Apidog CLI เป็นขั้นตอนการบิลด์ของ TeamCity ผลลัพธ์คือไปป์ไลน์ที่จะทำให้การบิลด์ล้มเหลวทันทีที่ API ของคุณหยุดทำงาน ก่อนที่การตอบสนองที่ไม่ดีจะไปถึงผู้ใช้
สิ่งที่คุณจะสร้าง
เมื่อเสร็จสิ้น คุณจะมี:
- โปรเจกต์ TeamCity ที่เชื่อมต่อกับ Git repository ของคุณ
- การกำหนดค่าบิลด์ที่มีทริกเกอร์ VCS ที่ทำงานทุกครั้งที่มีการ Push
- ขั้นตอนการบิลด์ที่รันชุดทดสอบ API ของคุณผ่าน Apidog CLI
- ผลการทดสอบที่ถูกแยกวิเคราะห์และสามารถมองเห็นได้ในแท็บ Tests ของ TeamCity
- บิลด์ที่เปลี่ยนเป็นสีแดงและบล็อกการผสานเมื่อปลายทางเสีย
รูปแบบเดียวกันนี้ใช้ได้กับบริการภายในขนาดเล็กหรือ API สาธารณะที่มีปลายทางหลายร้อยรายการ คุณสามารถปรับขนาดได้โดยการเพิ่มสถานการณ์การทดสอบใน Apidog ไม่ใช่โดยการแก้ไขโค้ดไปป์ไลน์
ทำไมการทดสอบ API ควรอยู่ใน TeamCity ไม่ใช่แค่บนเครื่องของคุณ
การทดสอบในเครื่องมีข้อบกพร่องร้ายแรงหนึ่งข้อ: มันขึ้นอยู่กับว่ามีคนจำได้ที่จะรันมัน CI กำจัดมนุษย์ออกจากวงจร ทุกการคอมมิตจะทริกเกอร์ชุดทดสอบเดียวกัน ในสภาพแวดล้อมเดียวกัน ด้วยการยืนยันเดียวกัน ไม่มีคำว่า "มันทำงานได้บนเครื่องของฉัน" เพราะไม่มีเครื่องจักร มีเพียง Build Agent ที่รันขั้นตอนที่คุณกำหนดไว้อย่างแม่นยำ
TeamCity เหมาะสำหรับเรื่องนี้ด้วยเหตุผลที่ชัดเจนหลายประการ:
- Build chains. คุณสามารถทำให้ขั้นตอนการทดสอบ API ขึ้นอยู่กับขั้นตอนการปรับใช้ (deploy) ไปยัง Staging เพื่อให้การทดสอบทำงานกับบิลด์ที่ปรับใช้ใหม่เสมอ ไม่ใช่บิลด์เก่า
- Test history. TeamCity ติดตามว่าการทดสอบใดผ่านและล้มเหลวในการบิลด์หลายร้อยครั้ง เมื่อการทดสอบเริ่มไม่เสถียร คุณจะเห็นว่าคอมมิตใดเป็นต้นเหตุ
- Investigation and muting. ปลายทางที่ทำงานผิดพลาดสามารถถูกปิดเสียง (muted) และมอบหมายให้เจ้าของได้ แทนที่จะบล็อกการผสานของทุกคน
- Agent pools. ชุดทดสอบที่ใหญ่จะรันบน Agent เฉพาะเพื่อให้ไม่ทำให้การบิลด์คอมไพล์ของคุณช้าลง
ข้อเสียคือ TeamCity ไม่ทราบวิธีเรียกใช้ API ของคุณหรือตรวจสอบการตอบกลับ มันจะรันคำสั่งใดก็ตามที่คุณให้มัน ดังนั้นงานจริงคือการสร้างคำสั่งเดียวที่รันชุด API ทั้งหมดของคุณและออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อมีบางอย่างล้มเหลว นั่นคือจุดที่การออกแบบการทดสอบมีความสำคัญ
ขั้นตอนที่ 1: ออกแบบและตรวจสอบการทดสอบ API ของคุณใน Apidog
ก่อนที่จะแตะต้อง TeamCity คุณต้องมีการทดสอบที่สามารถรันได้โดยไม่ต้องมีคนดูแล การทดสอบที่ต้องให้คุณตรวจสอบการตอบกลับ JSON ด้วยตาเปล่าไร้ประโยชน์ใน CI การตรวจสอบทุกครั้งต้องเป็นการยืนยันที่เครื่องสามารถประเมินได้: รหัสสถานะคือ 200, ฟิลด์ id เป็นตัวเลข, การตอบกลับมาภายใน 800 ms
Apidog ถูกสร้างมาเพื่อสิ่งนี้โดยเฉพาะ คุณออกแบบคำขอ จากนั้นแนบ การยืนยัน API ที่ตรวจสอบการตอบกลับโดยอัตโนมัติ; รหัสสถานะ, การปฏิบัติตาม JSON Schema, ค่าฟิลด์เฉพาะ, เวลาตอบสนอง คุณสามารถเชื่อมโยงคำขอเข้ากับสถานการณ์เพื่อให้ผลลัพธ์ของการเรียกเข้าสู่ระบบป้อนโทเค็นเข้าสู่คำขอถัดไป ไม่จำเป็นต้องเขียนสคริปต์สำหรับกรณีทั่วไป และมีสคริปต์เต็มรูปแบบเมื่อคุณต้องการ
สถานการณ์ที่สมจริงสำหรับ API อีคอมเมิร์ซอาจมีลักษณะดังนี้:
- POST
/auth/loginด้วยข้อมูลรับรองการทดสอบ, ยืนยัน200, ดึงโทเค็น Bearer ไปยังตัวแปร - GET
/products?category=booksด้วยโทเค็นนั้น, ยืนยัน200, ยืนยันว่าการตอบกลับเป็นอาร์เรย์, ยืนยันว่าทุกรายการมีpriceมากกว่า 0 - POST
/cart/itemsด้วยรหัสสินค้า, ยืนยัน201, ยืนยันว่ายอดรวมของตะกร้าที่ส่งคืนตรงกับราคาสินค้า - GET
/cart, ยืนยันว่าจำนวนสินค้าคือ 1
แต่ละขั้นตอนมีการยืนยันที่ผ่านหรือล้มเหลวด้วยตัวเอง รันสถานการณ์ภายใน Apidog ก่อนและยืนยันว่ามันเป็นสีเขียวกับสภาพแวดล้อม Staging ของคุณ หากไม่สามารถผ่านได้เมื่อคุณรันด้วยตนเอง มันก็จะไม่ผ่านใน CI จัดกลุ่มสถานการณ์ที่เกี่ยวข้องเข้าใน ชุดทดสอบ เพื่อให้คุณสามารถรันทั้งหมดด้วยคำสั่งเดียวแทนที่จะรันทีละสถานการณ์
ข้อดีของการสร้างการทดสอบด้วยวิธีนี้คือสถานการณ์เดียวกันที่คุณใช้สำหรับการดีบักด้วยตนเองกลายเป็นชุด CI ของคุณ คุณไม่ต้องดูแลชุดการทดสอบสองชุดที่ขนานกัน; ชุดหนึ่งใน GUI สำหรับการสำรวจ, อีกชุดหนึ่งในโค้ดสำหรับการทำงานอัตโนมัติ มันเป็นแหล่งข้อมูลเดียวที่เป็นจริง หากคุณมาจากเฟรมเวิร์กที่เน้นโค้ดเป็นหลักอย่าง REST Assured นี่คือส่วนที่ช่วยประหยัดเวลาได้มากที่สุด: คุณหยุดเขียนและเขียนซ้ำโค้ดคำขอ/การยืนยันที่ซ้ำซ้อนสำหรับทุกปลายทาง
ดาวน์โหลด Apidog หากคุณต้องการสร้างตาม ฟรีสำหรับเริ่มต้น และ CLI เป็นส่วนหนึ่งของชุดเครื่องมือเดียวกัน
ขั้นตอนที่ 2: ทำให้ Apidog CLI ทำงานในเครื่องก่อน
อย่าดีบักคำสั่งใหม่เป็นครั้งแรกใน CI วงจรการตอบสนองในเซิร์ฟเวอร์ CI นั้นโหดร้าย; คุณ Push, รอ Agent, อ่านบันทึก, แก้ไขอักขระตัวเดียว, Push อีกครั้ง พิสูจน์ว่าคำสั่งทำงานได้บนเครื่องของคุณ จากนั้นคัดลอกเวอร์ชันที่ใช้งานได้ไปยัง TeamCity
Apidog CLI ทำงานบน Node.js ดังนั้นติดตั้งทั่วโลกด้วย npm:
npm install -g apidog-cli
ยืนยันว่ามีอยู่:
apidog --version
ตอนนี้รันสถานการณ์การทดสอบของคุณ CLI สามารถรันสถานการณ์หรือชุดทดสอบโดยตรงจากโปรเจกต์ Apidog ของคุณโดยอ้างอิง ID ของมัน, ยืนยันตัวตนด้วย Access Token หรือจากไฟล์ที่ส่งออกในเครื่อง วิธีการออนไลน์จะรักษาการทดสอบของคุณให้เป็นแหล่งข้อมูลเดียวที่เป็นจริง; สิ่งที่ทีมของคุณแก้ไขใน Apidog คือสิ่งที่รันใน CI โดยไม่มีขั้นตอนการส่งออกให้ลืม
สร้าง Access Token จากการตั้งค่าบัญชี Apidog ของคุณ จากนั้นรัน:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-e "$APIDOG_ENV_ID" \
-r cli,html,junit
มีบางสิ่งที่ควรสังเกตที่นี่:
--access-tokenใช้สำหรับการยืนยันตัวตนการรัน ส่งผ่านในบรรทัดแบบนี้ หรือเข้าสู่ระบบครั้งเดียวด้วยapidog login --with-token-eเลือกสภาพแวดล้อมที่จะรัน; Staging, Production-readonly, หรืออะไรก็ตามที่คุณกำหนดไว้ใน Apidog คุณสามารถชี้การทดสอบเดียวกันไปยัง Base URL ที่แตกต่างกันได้โดยการเปลี่ยน ID นี้-rเลือกตัวรายงาน (reporter)cliพิมพ์ผลลัพธ์ที่มนุษย์อ่านได้ไปยังคอนโซล,htmlสร้างรายงานที่คุณสามารถเรียกดูได้ และรายงานในรูปแบบ JUnit คือสิ่งที่ทำให้ TeamCity สามารถแยกวิเคราะห์และแสดงผลการทดสอบแต่ละรายการได้
เมื่อการรันเสร็จสิ้น CLI จะออกด้วยรหัส 0 หากทุกอย่างผ่าน และรหัสที่ไม่ใช่ศูนย์หากมีการยืนยันใดๆ ล้มเหลว รหัสการออกนี้คือทั้งหมดใน CI: การออกด้วยรหัสที่ไม่ใช่ศูนย์คือสิ่งที่บอก TeamCity ให้ทำเครื่องหมายว่าบิลด์ล้มเหลว
สำหรับการทดสอบที่ต้องรันผ่านข้อมูลป้อนเข้าหลายรายการ CLI รองรับการรันแบบ Data-driven ชี้ไปยังไฟล์ CSV หรือ JSON และมันจะวนซ้ำสถานการณ์หนึ่งครั้งต่อแถว:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-d test-data/checkout-cases.csv \
-r cli,junit
นี่คือวิธีที่คุณทดสอบรหัสผลิตภัณฑ์นับร้อยหรือตารางของ Payload ที่ไม่ถูกต้องโดยไม่ต้องเขียนสถานการณ์นับร้อย แถวแต่ละแถวจะกลายเป็นการวนซ้ำของตัวเองพร้อมกับผลลัพธ์การผ่าน/ล้มเหลวของตัวเอง
เมื่อคุณเห็นผลลัพธ์สีเขียวในเครื่องแล้ว คุณก็มีคำสั่งที่เชื่อถือได้ คัดลอกมัน คำสั่งที่แน่นอนนั้นคือสิ่งที่เข้าสู่ TeamCity
ขั้นตอนที่ 3: เชื่อมต่อ TeamCity กับ Repository ของคุณ
ตอนนี้เปลี่ยนไปที่ TeamCity เป้าหมายของขั้นตอนนี้คือการให้ TeamCity มีโปรเจกต์, ชี้ไปที่โค้ดของคุณ และปล่อยให้มันทริกเกอร์บิลด์ทุกครั้งที่มีการ Push
หากคุณกำลังรัน TeamCity เป็นครั้งแรก เส้นทางที่ง่ายที่สุดคือ Official Docker image มันจะทำให้คุณมีเซิร์ฟเวอร์ที่ใช้งานได้ภายในไม่กี่นาที:
docker run -d --name teamcity-server \
-v ~/teamcity/datadir:/data/teamcity_server/datadir \
-v ~/teamcity/logs:/opt/teamcity/logs \
-p 8111:8111 \
jetbrains/teamcity-server
เปิด http://localhost:8111, ทำการตั้งค่าเริ่มต้น (การเลือกฐานข้อมูล, บัญชีผู้ดูแลระบบ) และคุณจะมาถึง Dashboard การตั้งค่า Production ใช้ฐานข้อมูลภายนอกที่เหมาะสมและ Build Agent เฉพาะ แต่สำหรับการติดตามคู่มือนี้ Agent ที่มาพร้อมกันก็เพียงพอแล้ว
สร้างโปรเจกต์:
- ไปที่ Administration และเลือก Create project
- เลือก From a repository URL และวาง Git remote ของคุณ (HTTPS หรือ SSH)
- เพิ่มข้อมูลรับรองหาก repo เป็นส่วนตัว; Deploy Key หรือ Personal Access Token
- TeamCity สแกน repo และต้องตรวจจับขั้นตอนการบิลด์โดยอัตโนมัติ คุณสามารถปล่อยให้มันทำได้ แต่สำหรับการทดสอบ API การกำหนดค่าขั้นตอนด้วยตนเองในส่วนถัดไปจะดีกว่า
TeamCity สร้าง VCS root (การเชื่อมต่อกับ repo ของคุณ) และ Build Configuration (ชุดขั้นตอนที่รัน) เมื่อมี VCS root แล้ว ให้ตั้งค่าทริกเกอร์เพื่อให้บิลด์ทำงานโดยอัตโนมัติ:
- เปิด Build Configuration ของคุณและไปที่ Triggers
- เพิ่ม VCS Trigger
- ปล่อยให้กฎเริ่มต้นเป็นเช่นนั้นเพื่อให้ทุกการเปลี่ยนแปลงในสาขาที่ถูกเฝ้าดูจะจัดคิวบิลด์
จากนี้ไป ทุกการ Push ไปยัง Repository ของคุณจะเริ่มการบิลด์ ตอนนี้บิลด์นั้นไม่ได้ทำอะไรที่เป็นประโยชน์; ขั้นตอนถัดไปจะให้คำสั่งทดสอบ API แก่มัน
ขั้นตอนที่ 4: เพิ่ม Apidog CLI เป็นขั้นตอนการบิลด์
นี่คือหัวใจของการตั้งค่า คุณกำลังเพิ่มขั้นตอนการบิลด์ที่จะติดตั้ง CLI บน Agent และรันชุดทดสอบของคุณ
ในการกำหนดค่าบิลด์ของคุณ ให้เปิด Build Steps และเพิ่มขั้นตอนใหม่ประเภท Command Line เลือก Custom script และวาง:
#!/bin/bash
set -e
# ติดตั้ง Apidog CLI บน build agent
npm install -g apidog-cli
# รันชุดทดสอบ API และสร้างรายงาน JUnit สำหรับ TeamCity
apidog run \
--access-token "%env.APIDOG_ACCESS_TOKEN%" \
-e "%env.APIDOG_ENV_ID%" \
-r cli,junit \
--out-dir reports
นั่นคือคำสั่งเดียวกับที่คุณพิสูจน์แล้วในเครื่อง โดยมีการเปลี่ยนแปลงสองอย่างสำหรับ CI อย่างแรก set -e ทำให้สคริปต์หยุดทำงานเมื่อเกิดข้อผิดพลาดใดๆ อย่างที่สอง ความลับถูกอ้างอิงเป็นพารามิเตอร์ของ TeamCity (%env.APIDOG_ACCESS_TOKEN%) แทนที่จะเป็น Hardcoded; คุณจะกำหนดค่าเหล่านั้นในขั้นตอนถัดไป
หาก Build Agent ของคุณยังไม่มี Node.js ให้ติดตั้งในขั้นตอนก่อนหน้านี้ หรือใช้ Agent Image ที่มี Node.js Docker Image ของ TeamCity อย่างเป็นทางการและ Agent Pool ส่วนใหญ่มี Node.js ให้ใช้งาน คุณยังสามารถรันขั้นตอนทั้งหมดภายในคอนเทนเนอร์ Node ได้โดยการตั้งค่าขั้นตอนให้รันใน Docker Image เช่น node:20
รายละเอียดหนึ่งที่ควรถูกต้อง: CLI ต้องรัน *หลังจาก* API ของคุณถูกปรับใช้และสามารถเข้าถึงได้ หาก TeamCity กำลังทดสอบบริการที่เพิ่งปรับใช้กับ Staging ให้ทำให้การบิลด์ทดสอบขึ้นอยู่กับการบิลด์ปรับใช้โดยใช้ Snapshot Dependency หรือ Build Chain ซึ่งรับประกันว่าการทดสอบจะเรียกใช้เวอร์ชันของ API ที่คอมมิตนี้สร้างขึ้นเสมอ ไม่ใช่เวอร์ชันก่อนหน้า
ขั้นตอนที่ 5: จัดเก็บความลับเป็นพารามิเตอร์ของ TeamCity
Access Token ของคุณคือข้อมูลรับรอง มันไม่ควรอยู่ในสคริปต์บิลด์ ใน Repository ของคุณ หรือในบันทึกบิลด์ TeamCity มีที่สำหรับสิ่งนี้โดยเฉพาะ
- ในการกำหนดค่าบิลด์ของคุณ (หรือโปรเจกต์แม่ เพื่อใช้ร่วมกันในหลายการกำหนดค่า) ให้เปิด Parameters
- เพิ่มพารามิเตอร์ใหม่ชื่อ
env.APIDOG_ACCESS_TOKEN - ตั้งค่า Spec เป็น Password ซึ่งจะซ่อนค่าใน UI และลบออกจากบันทึกบิลด์
- วาง Apidog Access Token ของคุณเป็นค่า
- เพิ่ม
env.APIDOG_ENV_IDในลักษณะเดียวกันด้วย ID สภาพแวดล้อมของคุณ (อันนี้ไม่ใช่ความลับ แต่การเก็บไว้เป็นพารามิเตอร์ช่วยให้คุณสามารถเปลี่ยนสภาพแวดล้อมได้โดยไม่ต้องแก้ไขสคริปต์)
การกำหนดค่าเหล่านี้ในระดับโปรเจกต์แทนที่จะเป็นระดับ Build Configuration หมายความว่าทุก Build ที่ทดสอบ API ภายใต้โปรเจกต์นั้นจะสืบทอดค่าเหล่านี้ หมุนเวียนโทเค็นเพียงครั้งเดียว และทุกไปป์ไลน์จะได้รับค่าใหม่
พารามิเตอร์รหัสผ่านคือความแตกต่างระหว่างโทเค็นที่อยู่ใน TeamCity อย่างปลอดภัยกับโทเค็นที่รั่วไหลไปในไฟล์บันทึกที่ทั้งทีมสามารถอ่านได้ ปฏิบัติต่อมันเหมือนที่คุณปฏิบัติต่อรหัสผ่านฐานข้อมูล
ขั้นตอนที่ 6: แสดงผลการทดสอบในแท็บ Tests ของ TeamCity
บิลด์ที่เปลี่ยนเป็นสีแดงเพียงอย่างเดียวบอกคุณว่ามีบางอย่างเสีย บิลด์ที่แสดงว่า *การทดสอบใด* เสียบอกคุณว่าควรดูที่ไหน นั่นคือสิ่งที่รายงาน JUnit ให้คุณ
Reporter -r junit เขียนไฟล์ XML ในรูปแบบ JUnit ซึ่งเป็นรูปแบบมาตรฐานของผลการทดสอบ CI ที่ TeamCity อ่านได้โดยตรง คุณชี้ TeamCity ไปยังไฟล์นั้นด้วยคุณสมบัติการบิลด์ XML Report Processing
- เปิด Build Features ใน Build Configuration ของคุณ
- เพิ่ม XML report processing
- ตั้งค่าประเภทรายงานเป็น Ant JUnit
- ตั้งค่า Monitoring path ให้ตรงกับ Output ของคุณ เช่น
reports/*.xml
รันบิลด์ เปิดมันขึ้นมาและคลิกแท็บ Tests คุณจะเห็นแต่ละสถานการณ์และการยืนยันเป็นการทดสอบแต่ละรายการพร้อมสถานะผ่าน/ล้มเหลวและเวลาที่ใช้ เมื่อการทดสอบล้มเหลว TeamCity จะแสดงข้อความข้อผิดพลาดแบบ In-line เชื่อมโยงไปยังคอมมิตที่เป็นต้นเหตุ และติดตามมันในบิลด์ถัดไป หากการทดสอบเดียวกันล้มเหลวสองครั้งติดต่อกัน TeamCity สามารถระบุว่าเป็นความล้มเหลวใหม่แทนที่จะเป็นความล้มเหลวที่ไม่เสถียร
นี่คือผลตอบแทนของการเลือกเอาต์พุต JUnit ในตอนต้น หากไม่มีมัน ความล้มเหลวคือบิลด์สีแดงหนึ่งบิลด์และข้อความคอนโซลจำนวนมาก เมื่อมีมัน คุณจะได้รับประวัติการทดสอบที่มีโครงสร้าง ค้นหาได้ ที่เปลี่ยนจาก "บิลด์ API เสียหาย" เป็น "การยืนยันยอดรวมตะกร้าเริ่มล้มเหลวในคอมมิต a3f9c2"
ขั้นตอนที่ 7: ทำให้บิลด์ล้มเหลวและบล็อกการผสาน
จุดประสงค์ของทั้งหมดนี้คือเพื่อหยุดโค้ดที่ไม่ดีไม่ให้ผสาน สองสิ่งทำให้สิ่งนั้นเกิดขึ้น
ประการแรก คือรหัสการออก (exit code) เนื่องจาก Apidog CLI ออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อมีการยืนยันใดๆ ล้มเหลว และสคริปต์ของคุณใช้ set -e การทดสอบที่ล้มเหลวจะทำให้ขั้นตอนการบิลด์ล้มเหลว ซึ่งจะทำให้บิลด์ล้มเหลว คุณไม่จำเป็นต้องกำหนดค่าอะไรเพิ่มเติม; การทดสอบ API สีแดงคือบิลด์สีแดงโดยค่าเริ่มต้น
ประการที่สอง คือ Merge Gate หากทีมของคุณทำงานใน Pull Request หรือ Merge Request ให้กำหนดค่า Git Host ของคุณ (GitHub, GitLab, Bitbucket) ให้ต้องผ่านการตรวจสอบ TeamCity ก่อนที่จะผสาน TeamCity รายงานสถานะบิลด์กลับไปยังคอมมิตผ่านคุณสมบัติ Build Feature ที่ชื่อ Commit Status Publisher:
- เพิ่มคุณสมบัติ Commit Status Publisher Build Feature
- เลือกผู้ให้บริการ VCS Hosting ของคุณ
- เพิ่ม Access Token เพื่อให้ TeamCity สามารถโพสต์สถานะได้
ตอนนี้ผู้มีส่วนร่วมเปิด PR, TeamCity รันชุด API กับสาขาของพวกเขา และปุ่ม Merge จะยังคงปิดใช้งานอยู่จนกว่าชุดทดสอบจะเป็นสีเขียว สถานการณ์ฟิลด์ที่ถูกเปลี่ยนชื่อตั้งแต่ต้นคู่มือนี้จะถูกจับได้ที่นี่ บนสาขา ก่อนที่จะถึง Main
ไปป์ไลน์ที่สมบูรณ์และสมจริง
เมื่อนำชิ้นส่วนต่างๆ มารวมกัน Build Configuration ที่ทำงานได้สำหรับไปป์ไลน์การทดสอบ API จะมีลักษณะดังนี้:
- VCS root ที่ชี้ไปยัง Repository ของคุณ พร้อม VCS trigger บนสาขา Main และสาขา PR
- ขั้นตอนการบิลด์ 1: ปรับใช้บริการไปยังสภาพแวดล้อม Staging (หรือเริ่มใน Docker Container บน Agent)
- ขั้นตอนการบิลด์ 2: คำสั่ง Apidog CLI จากขั้นตอนที่ 4 โดยรันชุดทดสอบของคุณกับสภาพแวดล้อม Staging นั้น
- Build Features: การประมวลผลรายงาน XML ที่อ่าน
reports/*.xml - Build Features: Commit Status Publisher ที่รายงานกลับไปยัง Git Host ของคุณ
- พารามิเตอร์:
env.APIDOG_ACCESS_TOKEN(รหัสผ่าน) และenv.APIDOG_ENV_ID
สำหรับทีมที่เก็บการกำหนดค่า CI ทั้งหมดไว้ในระบบควบคุมเวอร์ชัน TeamCity รองรับการกำหนดทั้งหมดนี้ใน Kotlin DSL (.teamcity/settings.kts) ที่คอมมิตไปยัง Repo แทนที่จะคลิกผ่าน UI ขั้นตอนการบิลด์คือคำสั่ง apidog run เดียวกันไม่ว่าจะด้วยวิธีใด; DSL เพียงแค่อธิบายการกำหนดค่าเป็นโค้ดเพื่อให้มีการตรวจสอบและเวอร์ชันควบคู่ไปกับสิ่งอื่นๆ
คุณสามารถรันชุดทดสอบได้มากกว่าแค่ทุกการ Push เพิ่ม Schedule Trigger เพื่อรันชุด Regression Test ทั้งหมดทุกคืนกับ Staging เพื่อให้คุณจับการเปลี่ยนแปลงที่เกิดขึ้นระหว่างคอมมิตได้; Dependency ของบุคคลที่สามที่เปลี่ยนแปลงไป, ฐานข้อมูลที่เข้าสู่สถานะแปลกๆ การรัน API ในเวลากลางคืนเป็นการประกันที่ราคาถูกและช่วยป้องกันไม่ให้คอมมิตแรกของเช้าวันถัดไปสืบทอดสภาพแวดล้อมที่เสียหายเมื่อวานนี้
เปรียบเทียบกับแพลตฟอร์ม CI อื่นๆ
รูปแบบที่ใช้นี้สามารถพกพาได้ คำสั่งที่รันการทดสอบของคุณ (apidog run พร้อม Access Token และ JUnit Reporter) เหมือนกันไม่ว่า CI Server ใดจะเรียกใช้มัน มีเพียง Wrapper เท่านั้นที่เปลี่ยนไป:
- ใน GitHub Actions คุณจะใส่คำสั่งเดียวกันในขั้นตอน YAML ของ Workflow เราครอบคลุมเรื่องนี้ใน วิธีทำให้การทดสอบ API เป็นอัตโนมัติใน GitHub Actions
- ใน Jenkins มันจะอยู่ใน Stage ของ
Jenkinsfileดู วิธีผสานรวมการทดสอบอัตโนมัติของ Apidog กับ Jenkins สำหรับ CI/CD - กลยุทธ์ที่กว้างขึ้นในทุกแพลตฟอร์มอยู่ใน วิธีทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD
หากคุณยังคงเลือก CI Server การเปรียบเทียบเครื่องมือ CI/CD ที่ดีที่สุด ของเราจะอธิบายว่า TeamCity เหมาะสมกับทางเลือกอื่นอย่างไร จุดแข็งของ TeamCity คือ Build Chains, ประวัติการทดสอบที่ละเอียด และ Kotlin DSL; เป็นตัวเลือกที่แข็งแกร่งสำหรับทีมที่อยู่ในระบบนิเวศของ JetBrains อยู่แล้ว หรือกำลังรันไปป์ไลน์หลายขั้นตอนที่ซับซ้อน
ปัญหาที่พบบ่อยและวิธีแก้ไข
บิลด์หาคำสั่ง apidog ไม่พบ Node.js ไม่ได้ติดตั้งบน Agent หรือไดเรกทอรี npm bin แบบ Global ไม่ได้อยู่ใน PATH ของ Agent เพิ่มขั้นตอนการติดตั้ง Node ก่อนหน้านี้ใน Chain หรือรันขั้นตอนภายใน Docker Image node:20
การทดสอบผ่านในเครื่องแต่ล้มเหลวใน CI ด้วยข้อผิดพลาดในการเชื่อมต่อ Build Agent ไม่สามารถเข้าถึง API ของคุณได้ URL ของ Staging ที่สามารถแก้ไขได้บน VPN ของแล็ปท็อปของคุณอาจไม่สามารถเข้าถึงได้จาก Cloud Agent ยืนยันว่าสภาพแวดล้อมที่คุณเลือกด้วย -e ชี้ไปยัง Host ที่ Agent สามารถเข้าถึงได้จริง และการเข้าถึงเครือข่ายหรือกฎ Firewall ที่จำเป็นครอบคลุม Agent
การยืนยันตัวตนล้มเหลวเฉพาะใน CI เท่านั้น ตรวจสอบว่าพารามิเตอร์รหัสผ่านสะกดตรงตามที่สคริปต์อ้างอิงและโทเค็นยังไม่หมดอายุ ข้อผิดพลาดที่พบบ่อยคือการกำหนด APIDOG_ACCESS_TOKEN ในขณะที่สคริปต์อ่าน %env.APIDOG_ACCESS_TOKEN%; คำนำหน้า env. มีความสำคัญ
การทดสอบไม่เสถียร; มันผ่านและล้มเหลวด้วยโค้ดเดียวกัน โดยปกติเป็นปัญหาเกี่ยวกับเวลาหรือลำดับข้อมูล ใช้การยืนยันเวลาตอบสนองของ Apidog เพื่อหาปลายทางที่ช้า และทำให้แต่ละสถานการณ์ตั้งค่าและลบข้อมูลของตัวเองเพื่อให้การรันไม่ขึ้นอยู่กับข้อมูลที่เหลือของกันและกัน คุณสมบัติ Mute-and-investigate ของ TeamCity ช่วยให้คุณสามารถกักกันการทดสอบที่ไม่เสถียรเพื่อไม่ให้บล็อกทุกคนในขณะที่คุณแก้ไขสาเหตุหลัก
แท็บ Tests ว่างเปล่าแม้ว่าบิลด์จะรันแล้ว เส้นทางประมวลผลรายงาน XML ไม่ตรงกับที่ CLI เขียนรายงาน ยืนยันว่า --out-dir ในคำสั่งและ Monitoring Path ใน Build Feature ชี้ไปที่เดียวกัน
คำถามที่พบบ่อย
ฉันจำเป็นต้องเขียนโค้ดเพื่อรันการทดสอบ API ใน TeamCity หรือไม่? ไม่ คุณออกแบบการทดสอบด้วยภาพใน Apidog ด้วย Assertion และ "โค้ด" เดียวใน TeamCity คือคำสั่ง apidog run บรรทัดเดียวในขั้นตอนการบิลด์แบบ Command Line นั่นคือความแตกต่างหลักจากวิธีการที่เน้นโค้ดเป็นหลักอย่าง REST Assured ซึ่งแต่ละปลายทางจำเป็นต้องมีโค้ดคำขอและการยืนยันที่เขียนด้วยมือ
ฉันสามารถรันการทดสอบกับสภาพแวดล้อมที่แตกต่างกันได้หรือไม่? ได้ กำหนดแต่ละสภาพแวดล้อม (Staging, Pre-prod, Production-readonly) ใน Apidog จากนั้นเปลี่ยนว่าอันไหนจะรันใน CI โดยการเปลี่ยนพารามิเตอร์ ID ของสภาพแวดล้อม -e การทดสอบเดียวกันจะรันกับสภาพแวดล้อมใดก็ได้โดยการชี้ไปยัง Base URL ที่แตกต่างกัน
ฉันจะรักษา Access Token ของฉันให้ปลอดภัยใน TeamCity ได้อย่างไร? จัดเก็บเป็นพารามิเตอร์ของ TeamCity ด้วยคุณสมบัติ Password ซึ่งจะซ่อนมันใน UI และลบออกจากบันทึกบิลด์ ห้าม Hardcode ในสคริปต์บิลด์หรือคอมมิตไปยัง Repository ของคุณ กำหนดไว้ที่ระดับโปรเจกต์เพื่อให้คุณสามารถหมุนเวียนได้ครั้งเดียวสำหรับทุกไปป์ไลน์
การทดสอบ API ที่ล้มเหลวจะบล็อกการผสานจริงหรือไม่? ใช่ โดยมีสองส่วนอยู่ในตำแหน่ง Apidog CLI ออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อมีการยืนยันใดๆ ล้มเหลว ซึ่งทำให้บิลด์ของ TeamCity ล้มเหลว เพิ่มคุณสมบัติ Build Feature ของ Commit Status Publisher และกำหนดให้ต้องมีการตรวจสอบในกฎการป้องกันสาขาของ Git Host ของคุณ และปุ่ม Merge จะยังคงปิดใช้งานอยู่จนกว่าชุดทดสอบจะผ่าน
อะไรคือความแตกต่างระหว่างการรันการทดสอบแบบออนไลน์กับการรันจากไฟล์ที่ส่งออก? การรันออนไลน์ด้วย Project ID และ Access Token หมายความว่าการทดสอบของคุณใน Apidog เป็นแหล่งข้อมูลเดียวที่เป็นจริง; สิ่งที่ทีมแก้ไขคือสิ่งที่รันใน CI การรันจากไฟล์ที่ส่งออกจะตรึงการทดสอบไว้กับเวอร์ชันที่คอมมิตใน Repo ของคุณ การรันออนไลน์จะง่ายกว่าในการรักษาข้อมูลให้ตรงกัน; การส่งออกจะให้การทดสอบที่เดินทางไปพร้อมกับโค้ด ทีมส่วนใหญ่เริ่มจากการรันออนไลน์
ฉันสามารถรันชุด Regression Test ทั้งหมดตามกำหนดเวลาแทนที่จะรันทุกครั้งที่ Push ได้หรือไม่? ได้ เพิ่ม Schedule Trigger ไปยัง Build Configuration เพื่อรันทุกคืน (หรือทุกชั่วโมง) กับ Staging หลายทีมรันชุด Smoke Test ที่รวดเร็วทุกครั้งที่ Push และชุด Regression Test ทั้งหมดตามกำหนดเวลากลางคืน เพื่อให้ Feedback ที่รวดเร็วและความครอบคลุมที่ลึกซึ้งไม่แย่งเวลาเดียวกัน
สรุป
ไปป์ไลน์ TeamCity ที่รันการทดสอบ API ของคุณในทุกคอมมิตจะเปลี่ยนสภาพเศรษฐกิจของปลายทางที่เสียหาย แทนที่จะให้ลูกค้าพบข้อบกพร่อง บิลด์จะเป็นผู้พบมัน; บนสาขา ก่อนการผสาน พร้อมการยืนยันที่ล้มเหลวอย่างแม่นยำและคอมมิตที่เป็นสาเหตุที่แสดงในแท็บ Tests
การตั้งค่าประกอบด้วยสามส่วนหลัก: การทดสอบพร้อมการยืนยันจริงที่คุณสร้างใน Apidog, คำสั่ง apidog run เพียงคำสั่งเดียวที่รันแบบ Headless และออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อล้มเหลว และ Build Configuration ของ TeamCity ที่รันคำสั่งนั้น, แยกวิเคราะห์ผลลัพธ์ JUnit และรายงานสถานะกลับไปยัง Git Host ของคุณ เมื่อตั้งค่าเสร็จแล้ว คุณจะรักษาสภาพครอบคลุมโดยการเพิ่มสถานการณ์ใน Apidog ไม่ใช่โดยการแตะต้องโค้ดไปป์ไลน์
ดาวน์โหลด Apidog เพื่อออกแบบชุดทดสอบแรกของคุณ พิสูจน์คำสั่ง CLI ในเครื่อง จากนั้นนำไปใส่ใน TeamCity ตั้งแต่นั้นเป็นต้นมา API ของคุณจะถูกทดสอบด้วยวิธีเดียวกันในทุกคอมมิต ไม่ว่าใครจะจำได้ที่จะรันมันหรือไม่ก็ตาม