Karate API Testing: คู่มือฉบับปฏิบัติเพื่อทำความเข้าใจ DSL

คุณต้องการการทดสอบ API ที่อ่านง่ายเหมือนภาษาอังกฤษทั่วไป อยู่ใน Git ข้างโค้ดของคุณ และสามารถทำงานได้ใน CI pipeline ใดก็ได้ Karate ถูกสร้างมาเพื่อสิ่งนั้นโดยเฉพาะ มันใช้ภาษาเฉพาะโดเมน (DSL) เพื่อให้คุณเขียนการทดสอบเป็นขั้นตอน Given / When / Then แทนที่จะเป็นเมธอด Java คู่มือนี้จะอธิบายว่า Karate คืออะไร ไฟล์ feature ทำงานอย่างไร และตัวอย่างที่สามารถรันได้

Karate คืออะไร

Karate เป็นเฟรมเวิร์กการทดสอบ API แบบโอเพนซอร์สที่ใช้ Java คุณอธิบายการทดสอบแต่ละครั้งเป็น scenario ในไฟล์ .feature โดยใช้ Gherkin ซึ่งเป็นโครงสร้าง Given/When/Then เดียวกันที่มาจาก Behavior-Driven Development ความแตกต่างจากเครื่องมืออย่าง Cucumber คือคุณไม่จำเป็นต้องเขียนโค้ด step-definition glue Karate มาพร้อมกับ HTTP steps, assertions และการจัดการ JSON ในตัว ดังนั้นการทดสอบ API ที่ทำงานได้จึงไม่จำเป็นต้องใช้ Java เลย

โปรเจกต์นี้มาพร้อมกับความสามารถที่มากกว่าการทดสอบ API Repository ประกอบด้วยโมดูลสำหรับการจำลอง (mocks), การทดสอบประสิทธิภาพ (ผ่าน Gatling) และระบบอัตโนมัติของ UI สำหรับคู่มือนี้ จุดเน้นหลักคือแกนหลักของการทดสอบ API ซึ่งเป็นสิ่งที่ทีมส่วนใหญ่เลือกใช้เป็นอันดับแรก

เนื่องจากการทดสอบเป็นไฟล์ข้อความธรรมดา จึงสามารถจัดการเวอร์ชันได้ดี การดู pull request diff จะแสดงให้เห็นว่า assertion ใดที่มีการเปลี่ยนแปลง ซึ่งทำงานได้ดีกับการตรวจสอบโค้ดและเวิร์กโฟลว์ที่ใช้โค้ดและทำงานร่วมกับ Git ได้ดี

หากคุณยังใหม่กับรูปแบบ Given/When/Then บทนำของเราเกี่ยวกับ Behavior-Driven Development จะอธิบายว่ามันมีที่มาอย่างไรและทำไมทีมถึงใช้มัน

วิธีการทำงาน: Feature Files และ karate-config.js

การทดสอบ Karate เริ่มต้นด้วยไฟล์ feature แต่ละไฟล์มีบล็อก Feature: หนึ่งบล็อก และบล็อก Scenario: หนึ่งบล็อกขึ้นไป ภายใน scenario คุณตั้งค่าคำขอด้วย Given, ส่งคำขอด้วย When และยืนยันผลลัพธ์ด้วย Then

นี่คือโครงสร้างที่ Quick Start ของ Karate แสดงให้เห็น:

Feature: User API

Scenario: List all users
  Given url 'https://jsonplaceholder.typicode.com'
  And path 'users'
  When method get
  Then status 200
  And match response == '#[10]'

อ่านจากบนลงล่าง url กำหนดที่อยู่ฐาน path เพิ่มทรัพยากร method get ส่งคำขอ status 200 ตรวจสอบรหัส HTTP บรรทัดสุดท้ายยืนยันว่าการตอบกลับเป็น JSON array ที่มี 10 รายการพอดี #[10] เป็น Karate marker ไม่ใช่ JavaScript ดูข้อมูลเพิ่มเติมเกี่ยวกับ markers เหล่านี้ในส่วน assertions

Gherkin ที่นี่เป็น Given/When/Then มาตรฐาน หากคุณต้องการเจาะลึกไวยากรณ์นั้นเพิ่มเติม โปรดดูคู่มือ Gherkin สำหรับ BDD และการทดสอบ API ของเรา

โปรเจกต์ส่วนใหญ่ต้องการค่าเฉพาะสำหรับสภาพแวดล้อม เช่น base URL สำหรับ dev, token สำหรับ staging, endpoint สำหรับ prod Karate จัดการสิ่งนี้ด้วยไฟล์เดียวชื่อ karate-config.js มันจะทำงานหนึ่งครั้งก่อนการทดสอบของคุณและคืนค่า config object ที่ทุก scenario สามารถอ่านได้

function fn() {
  var env = karate.env || 'dev';
  var config = {
    baseUrl: 'https://jsonplaceholder.typicode.com'
  };
  if (env === 'qa') {
    config.baseUrl = 'https://qa.example.com';
  }
  return config;
}

karate.env มาจาก system property ที่คุณส่งผ่านในขณะรันไทม์ คุณสามารถสลับสภาพแวดล้อมได้โดยไม่ต้องแตะไฟล์ feature ไฟล์เดียว ใน scenario คุณก็จะเขียน Given url baseUrl แทนที่จะฮาร์ดโค้ดที่อยู่

ตัวอย่าง Scenario

มาเขียนบางอย่างที่มี request body กัน Scenario นี้จะสร้างผู้ใช้ ตรวจสอบสถานะ และตรวจสอบความถูกต้องของโครงสร้างการตอบกลับ

Feature: Create user

Background:
  * url baseUrl

Scenario: Create a new user returns 201
  Given path 'users'
  And request { name: 'Ada', job: 'engineer' }
  When method post
  Then status 201
  And match response.name == 'Ada'
  And match response.id == '#string'

มีบางสิ่งที่ควรสังเกต บล็อก Background: จะทำงานก่อนแต่ละ scenario ในไฟล์ ดังนั้นคุณจึงตั้งค่า base URL เพียงครั้งเดียว * คือ wildcard step; Karate ถือว่า * เหมือนกับ Given, When หรือ Then ซึ่งช่วยให้คุณเขียนขั้นตอนการตั้งค่าได้โดยไม่ต้องกังวลเรื่องไวยากรณ์ คีย์เวิร์ด request รับ JSON payload โดยตรง ไม่ต้องมี serializer ไม่ต้องมี POJO และ #string คือ fuzzy matcher ที่ยืนยันว่าฟิลด์ id มีอยู่และเป็นสตริง โดยไม่จำเป็นต้องกำหนดค่าเฉพาะเจาะจง

Assertions และการจับคู่ JSON

Assertions คือจุดที่ Karate มีประโยชน์มาก คีย์เวิร์ดหลักคือ match มันจะเปรียบเทียบค่าจริงกับค่าที่คาดหวัง และจะทำให้การทดสอบล้มเหลวหากมีสิ่งใดไม่ตรงกัน

Exact match ตรวจสอบความเท่าเทียมกัน:

And match response == { id: '#number', name: 'Ada', job: 'engineer' }

โทเค็น #number, #string, #boolean และ #uuid เป็น fuzzy matchers พวกมันยืนยันประเภทและการมีอยู่โดยไม่เรียกร้องค่าตามตัวอักษร ซึ่งทำให้การทดสอบมีเสถียรภาพเมื่อเซิร์ฟเวอร์ส่งคืน ID หรือ timestamp ที่สร้างขึ้นมา

เมื่อคุณสนใจแค่บางฟิลด์ ให้ใช้ contains:

And match response contains { name: 'Ada' }

สิ่งนี้จะผ่านตราบเท่าที่ name เท่ากับ Ada แม้ว่าการตอบกลับจะมีฟิลด์อื่นอีกสิบฟิลด์ก็ตาม Karate ยังรองรับ !contains, contains only, contains any และ contains deep เพื่อการควบคุมที่ละเอียดยิ่งขึ้นในการจับคู่บางส่วน

คุณสามารถตรวจสอบ array ได้เช่นกัน match response == '#[10]' ยืนยัน array ที่มีความยาว 10 คุณสามารถใช้ schema กับทุกองค์ประกอบด้วย each:

And match each response == { id: '#number', name: '#string' }

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

การทดสอบที่ขับเคลื่อนด้วยข้อมูลและ CI

ชุดการทดสอบจริงจะรันตรรกะเดียวกันกับอินพุตหลายตัว Karate จัดการสิ่งนี้ด้วย Scenario Outline และตาราง Examples ตัวยึดตำแหน่งในวงเล็บมุมจะถูกเติมจากแต่ละแถว

Scenario Outline: Create users from a table
  Given url baseUrl
  And path 'users'
  And request { name: '<name>', job: '<job>' }
  When method post
  Then status 201
  And match response.name == '<name>'

  Examples:
    | name  | job       |
    | Ada   | engineer  |
    | Grace | scientist |
    | Alan  | analyst   |

สิ่งนี้จะรัน scenario สามครั้ง ครั้งละหนึ่งแถว คุณยังสามารถอ่านแถวจากไฟล์ภายนอกแทนตารางแบบอินไลน์ ซึ่งช่วยให้ชุดข้อมูลขนาดใหญ่อยู่นอกไฟล์ feature ของคุณ:

  Examples:
    | read('classpath:test-data/users.json') |

Karate อ่านไฟล์ JSON และ CSV ด้วยวิธีนี้ ดังนั้นข้อมูลการทดสอบของคุณจึงสามารถเก็บไว้ที่ใดก็ได้ที่ทีมของคุณต้องการจัดการ

สำหรับการทำ Continuous Integration คุณมีสองทางเลือก ในโปรเจกต์ Maven หรือ Gradle, Karate จะทำงานผ่าน JUnit 5 คุณเพิ่ม dependency karate-junit5 และชี้ runner ไปที่ไฟล์ feature ของคุณ ดังนั้น mvn test จะรันการทดสอบเหล่านั้นเหมือนการทดสอบหน่วยอื่นๆ นั่นหมายความว่าขั้นตอน CI ที่มีอยู่ของคุณไม่จำเป็นต้องมีเครื่องมือพิเศษใดๆ

เส้นทางที่สองคือ standalone jar ซึ่งไม่ต้องการเครื่องมือ build คุณสามารถดาวน์โหลด karate.jar จาก release ของโปรเจกต์และรันไฟล์ feature ได้โดยตรง โปรดทราบว่า jar ต้องการ Java เวอร์ชันล่าสุด ดังนั้นโปรดตรวจสอบ release notes สำหรับเวอร์ชันขั้นต่ำ

java -jar karate.jar src/test/java/features

คุณสามารถกรองด้วยแท็ก, รันแบบขนาน และเลือกไดเรกทอรีเอาต์พุตได้:

java -jar karate.jar --tags @smoke --threads 4 --output reports src/test/java/features

ส่งผ่านสภาพแวดล้อมด้วย system property ซึ่งจะส่งผ่านไปยัง karate.env ภายใน karate-config.js:

java -jar karate.jar -Dkarate.env=qa src/test/java/features

Karate จะเขียนรายงาน HTML ไปยังไดเรกทอรีเอาต์พุตหลังจากการรันแต่ละครั้ง เพื่อให้สามารถตรวจสอบความล้มเหลวได้ง่ายใน pipeline artifact สำหรับภาพรวม CI ที่กว้างขึ้น โปรดดูวิธีการทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD

จุดแข็งและข้อจำกัด

Karate มีจุดแข็งที่ชัดเจน การทดสอบอ่านได้ใกล้เคียงกับภาษาอังกฤษทั่วไป ซึ่งช่วยลดอุปสรรคสำหรับผู้ที่ไม่เชี่ยวชาญ Java การจับคู่ JSON ในตัว รวมถึง fuzzy matchers และ each ช่วยลด boilerplate ของ assertion ได้มาก ทุกอย่างอยู่ในไฟล์ข้อความภายใต้ Git ดังนั้นการตรวจสอบและเปรียบเทียบการทดสอบจึงทำได้เหมือนซอร์สโค้ด และครอบคลุมมากกว่า HTTP ดังนั้นทีมจึงสามารถเพิ่ม mocks หรือการทดสอบประสิทธิภาพได้ในภายหลังโดยไม่ต้องเปลี่ยนเครื่องมือ

ข้อจำกัดก็มีอยู่จริงเช่นกัน Karate ทำงานบน JVM ดังนั้นคุณต้องติดตั้ง Java และมีความคุ้นเคยกับระบบนิเวศของ JVM สำหรับสิ่งต่างๆ ที่นอกเหนือจากพื้นฐาน DSL เป็นสิ่งที่คุณต้องเรียนรู้ด้วยตัวเอง ไวยากรณ์อ่านง่าย แต่การเขียน matchers และรูปแบบการนำกลับมาใช้ใหม่ที่ถูกต้องต้องใช้การฝึกฝน ตรรกะที่นำกลับมาใช้ใหม่ได้, custom helpers และการตั้งค่าที่ซับซ้อนมักจะนำคุณกลับไปสู่ฟังก์ชัน JavaScript หรือ Java interop และเนื่องจากการทดสอบเป็นโค้ด นักพัฒนาที่ไม่ใช่โปรแกรมเมอร์ในทีมมักจะไม่สามารถเขียนหรือแก้ไขได้โดยปราศจากความช่วยเหลือ

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

Karate เทียบกับแนวทางที่ปราศจากโค้ด (Apidog)

Karate เป็นแบบโค้ดและทำงานร่วมกับ Git ได้ดี คุณเขียนไฟล์ feature, commit และรันมันจากเครื่องมือ build หรือ jar สิ่งนี้เหมาะสำหรับวิศวกรที่ต้องการให้การทดสอบอยู่ในระบบควบคุมเวอร์ชันถัดจากแอปพลิเคชัน และผู้ที่คุ้นเคยกับ JVM

Apidog เลือกเส้นทางแบบภาพที่ปราศจากโค้ดเพื่อบรรลุเป้าหมายเดียวกัน คุณสร้าง scenario การทดสอบใน UI, เชื่อมโยงคำขอ และเพิ่ม assertion ด้วยการคลิกแทนที่จะเขียน DSL เนื่องจากวงจรชีวิตของ API ทั้งหมด (การออกแบบ, การดีบัก, การจำลอง, เอกสารประกอบ) อยู่ในที่เดียว การทดสอบจึงสามารถนำ endpoint และ schema ที่คุณกำหนดไว้แล้วกลับมาใช้ใหม่ได้ ซึ่งช่วยลดอุปสรรคสำหรับวิศวกร QA และผู้ที่เกี่ยวข้องกับผลิตภัณฑ์ที่ไม่ต้องการจัดการโปรเจกต์ Java

ชุดการทดสอบแบบภาพไม่ได้ถูกจำกัดอยู่แค่ใน UI Apidog สามารถรันชุดการทดสอบเหล่านั้นแบบ headless ใน CI ผ่าน Apidog CLI ได้ ดังนั้นชุดการทดสอบแบบไม่ต้องเขียนโค้ดก็ยังคงเหมาะกับ pipeline อัตโนมัติ คุณติดตั้งได้ด้วย Node:

npm install -g apidog-cli

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

apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t <scenarioOrSuiteId> -e <environmentId> -r cli,html,junit

แฟล็ก -t กำหนดเป้าหมายเป็น scenario, โฟลเดอร์ หรือชุดการทดสอบ; -e เลือกสภาพแวดล้อม; -r เลือกหนึ่งตัวรายงานขึ้นไป (cli, html, json, junit) สำหรับการรันแบบขับเคลื่อนด้วยข้อมูล, -d (หรือ --iteration-data) ใช้เส้นทางไฟล์ข้อมูลหรือ test-data ID CLI เป็นแบบ headless และทำงานบนขั้นตอน CI ใดก็ได้ที่สามารถรัน Node ได้ มันรัน scenario Apidog ที่คุณบันทึกไว้ ไม่ใช่ตัวส่งคำขอแบบโต้ตอบหรือตัวสร้างโหลด ดูคำแนะนำฉบับเต็มได้ใน Apidog CLI สำหรับ CI/CD และการเปรียบเทียบกับ runner อื่นใน Apidog CLI เทียบกับ Newman

ทั้งสองแนวทางสร้างการทดสอบ API อัตโนมัติที่ทำงานแบบ headless ใน CI ความแตกต่างอยู่ที่รูปแบบการเขียน: Karate ต้องการให้คุณเขียน DSL ใน Git; Apidog ต้องการให้คุณคลิกใน UI ที่ส่งออกไปยัง pipeline ได้ด้วย

วิธีการเลือก

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

เลือกเครื่องมือแบบไม่ต้องเขียนโค้ดเช่น Apidog เมื่อผู้เขียนรวมถึง QA และผู้ที่เกี่ยวข้องกับผลิตภัณฑ์ เมื่อคุณต้องการให้การทดสอบเชื่อมโยงกับเวิร์กโฟลว์การออกแบบและเอกสารที่มีอยู่ หรือเมื่อคุณไม่ต้องการดูแลรักษา Java build เพื่อรันการตรวจสอบ API คุณยังคงได้รับการครอบคลุม CI ผ่าน CLI

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

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

ฉันจำเป็นต้องรู้ Java เพื่อใช้ Karate หรือไม่? ไม่ ไม่จำเป็นสำหรับการเขียนการทดสอบ API พื้นฐาน ไฟล์ feature ใช้ Gherkin DSL และ Karate มาพร้อมกับ HTTP และ assertion steps ในตัว คุณจะต้องติดตั้ง Java เพื่อรันการทดสอบ และความรู้ด้าน Java หรือ JavaScript บางส่วนจะช่วยได้เมื่อคุณต้องการ custom helpers หรือการนำกลับมาใช้ใหม่ที่ซับซ้อน

Karate แตกต่างจาก Cucumber อย่างไร? ทั้งคู่ใช้ไวยากรณ์ Given/When/Then ของ Gherkin สำหรับ Cucumber คุณจะเขียนโค้ด step-definition เพื่อรองรับแต่ละขั้นตอน Karate จัดเตรียมขั้นตอนการทดสอบ API ให้คุณ ดังนั้นจึงไม่มีโค้ด glue ที่ต้องดูแลรักษาสำหรับการทดสอบ HTTP มาตรฐาน

Karate สามารถทำงานได้โดยไม่มี Maven หรือ Gradle หรือไม่? ได้ คุณสามารถดาวน์โหลด karate.jar แบบ standalone จาก release ของโปรเจกต์และรันไฟล์ feature ด้วย java -jar karate.jar <path> มันรองรับแท็ก, parallel threads และไดเรกทอรีเอาต์พุตที่กำหนดเองโดยไม่ต้องใช้เครื่องมือ build ใดๆ

ไวยากรณ์ #string หรือ #[10] หมายความว่าอย่างไร? สิ่งเหล่านั้นคือ fuzzy matchers ของ Karate #string ยืนยันว่าฟิลด์เป็นสตริงที่มีค่าใดก็ได้ #number คือตัวเลข และ #[10] ยืนยัน JSON array ที่มีความยาว 10 สิ่งเหล่านี้ช่วยให้คุณสามารถตรวจสอบโครงสร้างการตอบกลับได้โดยไม่ต้องฮาร์ดโค้ดค่าที่สร้างขึ้นมา

การทดสอบ API ที่ปราศจากโค้ดยังสามารถทำงานใน CI ได้หรือไม่? ได้ เครื่องมือแบบภาพเช่น Apidog สามารถส่งออก scenario ที่บันทึกไว้ไปยัง Apidog CLI ซึ่งเป็นแบบ headless และทำงานบนขั้นตอน CI ใดก็ได้ที่ใช้ Node ดังนั้นคุณจึงสามารถเขียนการทดสอบใน UI และยังคงได้รับการรัน pipeline อัตโนมัติ