Thanawat Wongchai

Posted on Jun 25 • Originally published at apidog.com

Apidog CLI เทียบกับ Specmatic

หากคุณสร้าง API แบบ spec-first จุดตัดสินใจสำคัญคือ: คุณต้องการเครื่องมือที่เปลี่ยนไฟล์ OpenAPI ให้เป็น contract check ที่รันได้ทันที หรือคุณต้องการแพลตฟอร์มสำหรับออกแบบ จำลอง ทดสอบ และรัน API test ใน CI แบบครบวงจร? ทั้ง Specmatic และ Apidog CLI อยู่ในแนวทาง spec-first แต่แก้ปัญหาคนละชั้นของ workflow บทความนี้เปรียบเทียบแบบลงมือทำ โดยอ้างอิงแนวคิด การทดสอบสัญญา API และ ข้อกำหนด OpenAPI เป็นฐาน

ลองใช้ Apidog วันนี้

ฉบับย่อ

ใช้ Specmatic เมื่อคุณมี OpenAPI หรือสเปกอื่นอยู่แล้ว และต้องการบังคับใช้สัญญาระหว่าง service ให้ชัดเจน เช่น provider ต้องตอบตาม schema/status code ที่ประกาศไว้ และ consumer สามารถพัฒนากับ stub ที่สร้างจากสัญญาเดียวกันได้

ใช้ Apidog CLI เมื่อคุณต้องการ workflow เดียวตั้งแต่ design → mock → functional test → CI โดยออกแบบ API ใน Apidog สร้าง mock จาก schema เขียน test scenario แล้วรันแบบ headless ด้วย apidog run

สรุปสั้นๆ:

Specmatic เด่นเรื่อง contract-as-code, provider verification และ service virtualization
Apidog CLI เด่นเรื่อง API lifecycle: ออกแบบ จำลอง ทดสอบ functional flow และรันใน CI
ใช้ร่วมกันได้ หากทีมต้องการทั้ง workflow ครบวงจรและ contract gate ที่เข้มงวด

สิ่งที่ Specmatic ทำได้ดี

Specmatic มองว่า API spec คือ executable contract คุณชี้ไปที่ไฟล์ OpenAPI, AsyncAPI, GraphQL, gRPC หรือ WSDL แล้วให้เครื่องมือสร้าง test case จากสเปกโดยอัตโนมัติ ทั้ง positive และ negative scenario

Workflow พื้นฐานของ Specmatic

เขียนหรือ export API spec เช่น openapi.yaml
รัน service จริงใน environment ทดสอบ
ให้ Specmatic ยิง request ตามสัญญา
ถ้า response ไม่ตรง spec ให้ build fail
ใช้ spec เดียวกันสร้าง stub ให้ consumer พัฒนาต่อได้

ตัวอย่างแนวคิดใน pipeline:

# ตัวอย่างเชิงแนวคิด
# 1. start provider service
npm run start:test

# 2. run contract verification against OpenAPI spec
specmatic test openapi.yaml

จุดแข็งหลัก

Provider verification

ตรวจว่า service ที่รันจริงตอบตรงกับสเปกหรือไม่ เช่น field หายไป, status code เปลี่ยน, response body ไม่ตรง schema
Contract as stub

ใช้สเปกเดียวกันสร้าง stub เพื่อให้ consumer พัฒนาได้โดยไม่ต้องรอ provider จริง
เหมาะกับ microservices

เมื่อแต่ละ service deploy แยกกันและมีทีมดูแลต่างกัน contract test จะช่วยจับ breaking change ก่อนถึง staging หรือ production

Specmatic เป็นโอเพนซอร์สบน GitHub และมี CLI สำหรับ CI/CD พร้อมเลเยอร์เชิงพาณิชย์ เช่น Studio และ Insights นอกจากนี้ยังรองรับมากกว่า REST เช่น AsyncAPI, GraphQL, gRPC, WSDL และ event-driven backend อย่าง Kafka, JMS และ RabbitMQ

ข้อควรจำ: Specmatic ไม่ได้พยายามเป็น API design UI หรือ functional test suite แบบครบวงจร คุณค่าหลักเกิดขึ้นเมื่อคุณมีสเปกแล้ว และต้องการบังคับใช้สัญญานั้นอย่างจริงจัง

สิ่งที่ Apidog CLI ทำได้ดี

Apidog CLI คือ command-line runner สำหรับโปรเจกต์ Apidog คุณออกแบบ API, mock, และสร้าง test scenario ในแอป จากนั้นนำ test เหล่านั้นไปรันใน CI ด้วย apidog run รายละเอียด flag และ exit code ดูได้ใน เอกสารอ้างอิงคำสั่ง apidog run

Workflow พื้นฐานของ Apidog CLI

ออกแบบ API จาก OpenAPI หรือสร้าง spec ใน Apidog
สร้าง mock server จาก schema เพื่อให้ frontend/backend ทำงานขนานกัน
สร้าง test scenario เช่น login → create resource → verify response
เพิ่ม assertion และ data-driven iteration
รัน test ใน CI ด้วย apidog run

ตัวอย่างคำสั่งเชิง workflow:

# รัน test scenario จาก Apidog ในโหมด headless
apidog run

ตัวอย่างการใช้ใน CI แบบทั่วไป:

name: API Tests

on:
  push:
    branches: [main]

jobs:
  api-test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run Apidog tests
        run: apidog run

ปรับ token, project ID, environment และ flag ตามรูปแบบที่ระบุในเอกสารของโปรเจกต์คุณ

จุดแข็งหลักของ Apidog CLI

ออกแบบ Mock และ Test จากสเปกเดียวกัน

คุณสร้าง OpenAPI definition แบบ visual สร้าง mock ที่ขับเคลื่อนด้วย schema และเขียน assertion เทียบกับ response ได้ใน workflow เดียว ดูแนวทางเพิ่มเติมใน เวิร์กโฟลว์การจำลองแบบ Schema-first
รองรับ functional scenario

ไม่ได้ตรวจแค่ว่า response ตรง schema หรือไม่ แต่สามารถ chain request, ส่งค่าระหว่าง step, ตรวจค่าเฉพาะ field และรัน data-driven test ได้
รองรับหลายโปรโตคอล

REST, GraphQL, gRPC, SOAP และ WebSocket ใช้ workflow เดียวกันได้
เหมาะกับ CI/CD

apidog run ส่ง exit code และ report ที่ pipeline ใช้ตัดสิน build ได้ ดูตัวอย่าง workflow เพิ่มเติมใน คู่มือ Apidog CLI ฉบับสมบูรณ์

ข้อควรจำ: Apidog ตรวจ response เทียบกับ OpenAPI schema และรัน functional test ได้ดี แต่ไม่ได้ทำหน้าที่เป็น Contract Broker แบบ Pact สำหรับ consumer/provider repo ที่แยกกันโดยตรง หากโจทย์หลักคือ formal consumer-driven contract testing ระหว่างหลาย repository จุดแข็งจะอยู่ที่ Specmatic มากกว่า

การเปรียบเทียบแบบเจาะลึก

ขอบเขต	Specmatic	Apidog CLI
จุดเน้นหลัก	Contract-as-code, provider verification, contract stub	Design-first, mock, functional test, CI execution
การสร้าง test	สร้าง positive/negative test จาก spec อัตโนมัติ	สร้าง scenario แบบ visual พร้อม schema validation
Consumer/provider contract	จุดแข็งหลัก	ตรวจ schema ได้ แต่ไม่ใช่ Contract Broker
Mock	Service virtualization จาก contract	Mock server จาก OpenAPI schema
โปรโตคอล	OpenAPI, AsyncAPI, GraphQL, gRPC, WSDL, messaging เช่น Kafka/JMS	REST, GraphQL, gRPC, SOAP, WebSocket
Interface	CLI พร้อม Studio/Insights เชิงพาณิชย์	Visual app พร้อม `apidog run` CLI
Functional/E2E workflow	เบากว่า เน้น contract scenario	แข็งแรงกว่า: chained steps, data-driven run, assertion
Open source	ใช่ใน core	มี free tier และเป็น commercial platform
เหมาะที่สุดกับ	บังคับใช้สัญญาระหว่าง service อิสระ	ออกแบบ จำลอง และทดสอบ API ตลอด lifecycle

เลือกเครื่องมืออย่างไร

เลือก Specmatic ถ้าโจทย์คือ contract ระหว่างทีม

เหมาะเมื่อคุณมีหลาย service ที่:

deploy แยกกัน
มีทีมดูแลต่างกัน
ใช้ shared API contract
มักเจอ breaking change ตอน integrate
ต้องการให้ build fail เมื่อ implementation ไม่ตรง spec

ตัวอย่าง use case:

Payment service เปลี่ยน response field
Order service ยัง expect field เดิม
Contract verification ต้องจับปัญหานี้ก่อน merge หรือ deploy

ในกรณีนี้ Specmatic ช่วยให้ provider verification และ stub จาก contract ทำงานเป็น CI gate ได้ตรงจุด

เลือก Apidog CLI ถ้าโจทย์คือ API workflow ครบวงจร

เหมาะเมื่อคุณต้องการ:

ออกแบบ OpenAPI ในที่เดียว
สร้าง mock ให้ frontend ใช้งานก่อน backend พร้อม
เขียน functional test ที่มีหลาย step
ตรวจ response schema และ business assertion
รัน test ทุกครั้งที่ push หรือ deploy

ตัวอย่าง scenario:

1. POST /login
2. เก็บ access_token จาก response
3. POST /orders ด้วย token
4. GET /orders/{id}
5. assert ว่า status = "created"
6. รันทั้งหมดด้วย apidog run ใน CI

หาก workflow ของคุณเริ่มจาก “เราต้องออกแบบ จำลอง และทดสอบ API นี้ให้เร็วขึ้น” Apidog จะตรงกว่า โดยเฉพาะเมื่อทีมต้องการลดการสลับไปมาระหว่าง design tool, mock tool และ test runner

สำหรับภาพรวมเรื่องการทำงานร่วมกันระหว่าง contract testing และ mock server ดูเพิ่มเติมที่ การทดสอบสัญญาและเซิร์ฟเวอร์จำลอง

ใช้ Specmatic และ Apidog ร่วมกันได้ไหม?

ได้ และเป็นรูปแบบที่สมเหตุสมผลสำหรับทีมที่มีทั้ง API lifecycle และ contract governance

แนวทางหนึ่งคือ:

ใช้ OpenAPI เป็น source of truth
ออกแบบและดูแล API definition ใน Apidog
สร้าง mock server จาก schema เพื่อให้ consumer เริ่มพัฒนาได้เร็ว
เขียน functional test scenario ใน Apidog
รัน test ด้วย apidog run ใน CI
ใช้ Specmatic เพิ่มเติมใน service ที่ต้องการ provider contract verification อย่างเข้มงวด

Pipeline อาจแบ่ง gate ได้แบบนี้:

Pull Request
  ├─ lint/build/unit test
  ├─ apidog run             # functional API scenario
  └─ specmatic test         # provider contract verification

Apidog ดูแล design, mock, functional test และ CI execution ส่วน Specmatic ดูแล contract enforcement ระหว่าง service อิสระ เมื่อใช้ร่วมกันจะได้ทั้งความเร็วในการพัฒนาและความเข้มงวดของสัญญา

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

Apidog เป็นทางเลือกของ Specmatic หรือไม่?

สำหรับบางงานใช่ แต่ไม่ใช่การแทนที่แบบหนึ่งต่อหนึ่ง

ถ้าคุณต้องการออกแบบ API, mock, เขียน functional test และรันใน CI Apidog ครอบคลุม workflow เหล่านี้ได้ดี แต่ถ้าคุณต้องการ contract verification ระหว่าง consumer/provider ที่แยก repository และต้องการแนวทาง contract-as-code ที่เข้มงวด Specmatic ถูกสร้างมาเพื่อโจทย์นั้นโดยตรง

Apidog CLI ทำ contract testing หรือไม่?

Apidog ตรวจ response ของ API เทียบกับ OpenAPI schema ระหว่าง test run ซึ่งช่วยจับปัญหาเช่น field หาย, type ผิด หรือ response structure ไม่ตรง spec ได้ นี่เป็นรูปแบบ contract check ที่พบได้บ่อยสำหรับ API เดี่ยว

แต่ Apidog CLI ไม่ได้ทำหน้าที่เป็น Contract Broker แบบ Pact สำหรับ consumer/provider repo ที่แยกกัน หากต้องการแยกความต่างระหว่าง schema validation กับ broker-based contract testing อ่านต่อได้ที่ การทดสอบสัญญา API คืออะไร

ตัวไหนเหมาะกับ CI/CD มากกว่ากัน?

ทั้งคู่เหมาะกับ CI/CD แต่เหมาะกับ gate คนละประเภท

ใช้ Specmatic เมื่อ CI gate คือ “provider ต้องไม่ละเมิด contract”
ใช้ Apidog CLI เมื่อ CI gate คือ “API ต้องผ่าน functional scenario และ schema validation”
ใช้ ทั้งคู่ เมื่อระบบมี microservices หลายทีมและยังต้องมี API test flow แบบ end-to-end

ต้องเขียนโค้ดทดสอบเองหรือไม่?

ส่วนใหญ่ไม่จำเป็น

Specmatic สร้าง contract test จากสเปก
Apidog ให้สร้าง scenario และ assertion แบบ visual พร้อม data-driven run

ทั้งสองแนวทางลด test code ที่ต้องเขียนเองเมื่อเทียบกับ framework แบบ code-first

สรุป

Specmatic และ Apidog CLI เริ่มจากแนวคิด spec-first เหมือนกัน แต่แก้ปัญหาคนละระดับ

เลือก Specmatic ถ้าปัญหาหลักคือ service หลายตัวละเมิด contract ระหว่างกัน
เลือก Apidog CLI ถ้าคุณต้องการออกแบบ mock และรัน functional API test ใน CI จาก workflow เดียว
ใช้ ทั้งสองอย่างร่วมกัน ถ้าทีมต้องการทั้ง API lifecycle ที่รวดเร็วและ contract verification ที่เข้มงวด

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

DEV Community