Pengujian REST API dengan Karate

1. Ikhtisar

Pada artikel ini, kami akan memperkenalkan Karate, kerangka kerja pengujian Behavior Driven Development (BDD) untuk Java.

2. Karate dan BDD

Karate dibangun di atas Ketimun , kerangka pengujian BDD lain, dan berbagi beberapa konsep yang sama. Salah satunya adalah penggunaan file Gherkin, yang menjelaskan fitur yang diuji . Namun, tidak seperti Mentimun, pengujian tidak ditulis di Java dan dijelaskan sepenuhnya di file Gherkin.

File Gherkin disimpan dengan ekstensi ".feature" . Ini dimulai dengan kata kunci Fitur , diikuti dengan nama fitur di baris yang sama. Ini juga berisi skenario pengujian yang berbeda, masing-masing dimulai dengan kata kunci Skenario dan terdiri dari beberapa langkah dengan kata kunci Diberikan , Kapan , Lalu , Dan , dan Tapi .

Lebih lanjut tentang Ketimun dan struktur Gherkin dapat ditemukan di sini.

3. Ketergantungan Maven

Untuk menggunakan Karate dalam proyek Maven, kita perlu menambahkan ketergantungan apache-karate ke pom.xml :

 com.intuit.karate karate-apache 0.6.0 

Kami juga membutuhkan ketergantungan karate-junit4 untuk memfasilitasi pengujian JUnit:

 com.intuit.karate karate-junit4 0.6.0 

4. Membuat Tes

Kami akan mulai dengan menulis tes untuk beberapa skenario umum dalam file Fitur Gherkin .

4.1. Menguji Kode Status

Mari kita tulis skenario yang menguji titik akhir GET dan memeriksa apakah itu mengembalikan kode status HTTP 200 (OK):

Scenario: Testing valid GET endpoint Given url '//localhost:8097/user/get' When method GET Then status 200

Ini bekerja jelas dengan semua kemungkinan kode status HTTP.

4.2. Menguji Respon

Mari kita tulis skenario lain yang menguji bahwa titik akhir REST mengembalikan respons tertentu:

Scenario: Testing the exact response of a GET endpoint Given url '//localhost:8097/user/get' When method GET Then status 200 And match $ == {id:"1234",name:"John Smith"}

The pertandingan operasi digunakan untuk validasi mana ' $' mewakili respon. Jadi skenario di atas memeriksa apakah responsnya sama persis dengan ' {id: ”1234 ″, name:” John Smith ”}'.

Kami juga dapat memeriksa secara khusus untuk nilai bidang id :

And match $.id == "1234"

The pertandingan operasi juga dapat digunakan untuk memeriksa apakah respon berisi bidang-bidang tertentu. Ini berguna ketika hanya bidang tertentu yang perlu diperiksa atau ketika tidak semua bidang respons diketahui:

Scenario: Testing that GET response contains specific field Given url '//localhost:8097/user/get' When method GET Then status 200 And match $ contains {id:"1234"}

4.3. Memvalidasi Nilai Respons Dengan Penanda

Dalam kasus di mana kita tidak tahu nilai pasti yang dikembalikan, kita masih bisa memvalidasi nilai menggunakan penanda - tempat penampung untuk bidang yang cocok dalam respons.

Misalnya, kita dapat menggunakan marker untuk menunjukkan apakah kita mengharapkan nilai null atau tidak:

  • #batal
  • #notnull

Atau kita bisa menggunakan penanda untuk mencocokkan tipe nilai tertentu di bidang:

  • #boolean
  • #jumlah
  • #tali

Penanda lain tersedia ketika kita mengharapkan sebuah bidang berisi objek atau larik JSON:

  • #Himpunan
  • #obyek

Dan ada penanda untuk pencocokan pada format atau ekspresi reguler tertentu dan yang mengevaluasi ekspresi boolean:

  • #uuid - nilai sesuai dengan format UUID
  • #regex STR - nilai cocok dengan ekspresi reguler STR
  • #? EXPR - menegaskan bahwa ekspresi JavaScript EXPR bernilai true

Terakhir, jika kita tidak menginginkan jenis pemeriksaan apa pun pada bidang, kita dapat menggunakan penanda #ignore .

Mari tulis ulang skenario di atas untuk memeriksa bahwa field id bukan null :

Scenario: Test GET request exact response Given url '//localhost:8097/user/get' When method GET Then status 200 And match $ == {id:"#notnull",name:"John Smith"}

4.4. Menguji Titik Akhir POST Dengan Badan Permintaan

Mari kita lihat skenario terakhir yang menguji titik akhir POST dan mengambil isi permintaan:

Scenario: Testing a POST endpoint with request body Given url '//localhost:8097/user/create' And request { id: '1234' , name: 'John Smith'} When method POST Then status 200 And match $ contains {id:"#notnull"}

5. Menjalankan Tes

Sekarang setelah skenario pengujian selesai, kami dapat menjalankan pengujian kami dengan mengintegrasikan Karate dengan JUnit.

Kami akan menggunakan anotasi @CucumberOptions untuk menentukan lokasi persis file Fitur :

@RunWith(Karate.class) @CucumberOptions(features = "classpath:karate") public class KarateUnitTest { //... }

Untuk mendemonstrasikan REST API, kami akan menggunakan server WireMock.

Untuk contoh ini, kami memalsukan semua titik akhir yang sedang diuji dalam metode yang dianotasi dengan @BeforeClass . Kami akan mematikan server WireMock dengan metode yang dianotasi dengan @AfterClass :

private static WireMockServer wireMockServer = new WireMockServer(WireMockConfiguration.options().port(8097)); @BeforeClass public static void setUp() throws Exception { wireMockServer.start(); configureFor("localhost", 8097); stubFor( get(urlEqualTo("/user/get")) .willReturn(aResponse() .withStatus(200) .withHeader("Content-Type", "application/json") .withBody("{ \"id\": \"1234\", name: \"John Smith\" }"))); stubFor( post(urlEqualTo("/user/create")) .withHeader("content-type", equalTo("application/json")) .withRequestBody(containing("id")) .willReturn(aResponse() .withStatus(200) .withHeader("Content-Type", "application/json") .withBody("{ \"id\": \"1234\", name: \"John Smith\" }"))); } @AfterClass public static void tearDown() throws Exception { wireMockServer.stop(); }

Saat kita menjalankan kelas KarateUnitTest , REST Endpoints dibuat oleh WireMock Server, dan semua skenario dalam file fitur yang ditentukan dijalankan.

6. Kesimpulan

Dalam tutorial ini, kami melihat cara menguji REST API menggunakan Kerangka Pengujian Karate.

Kode sumber lengkap dan semua cuplikan kode untuk artikel ini dapat ditemukan di GitHub.