Gherkio v0.1.0-alpha.9: Redis, Repeat Workflow, dan Load Test

Di versi sebelumnya, Gherkio sudah cukup untuk mengirim request, menyimpan response, dan membuat assertion. Tapi setelah dipakai untuk beberapa workflow nyata, ada bagian yang masih harus aku periksa manual. Salah satunya adalah cache.

Response API bisa benar dan latency-nya rendah, tapi itu belum membuktikan bahwa data memang diambil dari Redis. Ada juga workflow yang harus memilih data dari response, mengecek apakah data tersebut masih dipakai, lalu mengulang proses sampai menemukan data yang valid.

Masalah-masalah itu menjadi fokus utama di v0.1.0-alpha.9. Release ini mencoba menyambungkan request API, state Redis, dan proses asynchronous dalam satu skenario yang tetap declarative.

Memeriksa cache melalui Redis

Awalnya aku sempat menghindari koneksi datastore di dalam DSL. Kalau semua command database dibuka, file test bisa berubah menjadi script bebas dan batas DSL-nya hilang.

Solusi yang aku pilih adalah koneksi Redis yang read-only. Gherkio hanya menyediakan get, exists, ttl, dan hgetall. Tidak ada write, delete, scan key, atau arbitrary command.

Koneksi didefinisikan di environment, bukan di file scenario:

baseUrl: http://localhost:8080

connections:
  application-cache:
    type: redis
    address: localhost:6379
    database: 0
    password: $GHERKIO_REDIS_PASSWORD
    timeout: 5s

Setelah request API selesai, key Redis bisa diperiksa di workflow yang sama:

steps:
  - name: Fetch product
    request:
      method: GET
      url: /v1/products/42
    expect:
      status: 200
      body.data.id: exists
    save:
      PRODUCT_ID: body.data.id

  - name: Wait for product cache
    redis:
      connection: application-cache
      command: get
      key: "product:$PRODUCT_ID"
    expect:
      redis.exists: true
      redis.value.id: "$PRODUCT_ID"
    retry:
      attempts: 10
      interval: 200
      backoff: constant

  - name: Check cache TTL
    redis:
      connection: application-cache
      command: ttl
      key: "product:$PRODUCT_ID"
    expect:
      redis.ttl: gt 0

Jika value dari GET berisi JSON, Gherkio akan decode value tersebut sehingga field seperti redis.value.id bisa langsung digunakan. Redis Sentinel juga didukung. Scenario-nya tetap sama, yang berubah hanya konfigurasi connection di environment.

Batas read-only ini penting buatku. Test bisa membuktikan bahwa aplikasi membuat atau menghapus cache, tetapi Gherkio sendiri tidak mengubah state Redis.

Mengulang beberapa step dengan repeat

Retry cocok jika satu request perlu dicoba lagi. Masalahnya berbeda ketika satu percobaan terdiri dari beberapa step.

Salah satu kasus yang aku temui ketika melakukan pengujian pada suatu api, tapi api tersebut membutuhkan prasyarat yang mana harus mencari data "Ticket" yang belum ada dengan "Tag Masalah Tertentu" terlebih dahulu. Secara manual check bisa dilakukan dengan melakukan request ke list ticket api dengan beberapa filter, jika hasilnya muncul maka tidak valid harus cari "Tag Masalah Lain".

Untuk kasus seperti ini, alpha.9 menambahkan bounded repeat block:

- name: Find unused issue tag
  repeat:
    attempts: 5
    until: $existingTicketCount == 0
    steps:
      - name: Select candidate
        set:
          ISSUE_TAG: ${randomItem(respIssueTags)}

      - name: Find tickets using candidate
        request:
          method: GET
          url: /tickets
          query:
            issue_tag_id: $ISSUE_TAG.id
        expect:
          status: 200
          body.data: array
        save:
          existingTicketCount: count(body.data)

randomItem(respIssueTags) menyimpan object secara utuh. Jadi $ISSUE_TAG.id dan $ISSUE_TAG.name selalu berasal dari item yang sama. Kalau hanya butuh satu field, syntax ${randomItem(respIssueTags,id)} tetap bisa digunakan.

Repeat harus memiliki batas attempts. Aku tidak ingin menambahkan recursion bebas ke DSL karena kesalahan kondisi bisa membuat test berjalan tanpa akhir. Jika kondisi until belum terpenuhi, step akan gagal dan report menampilkan setiap attempt.

Virtual user bukan sekadar parallel file

Sebelumnya --parallel digunakan untuk menjalankan beberapa file test secara bersamaan. Itu berbeda dengan load test terhadap satu workflow.

Sekarang satu file bisa dijalankan oleh beberapa virtual user:

gherkio run tests/create-ticket.yaml \
  --env staging \
  --virtual-users 2 \
  --iterations-per-user 3

Artinya ada dua virtual user yang berjalan bersamaan. Masing-masing user menjalankan workflow yang sama sebanyak tiga kali secara sequential. Totalnya enam workflow execution.

Setiap virtual user memiliki variable store sendiri. ID atau token dari VU pertama tidak bercampur dengan VU kedua. Report HTML menampilkan ringkasan VU, iteration, durasi, dan hasil setiap workflow.

Fitur ini berguna untuk mengulang workflow dan melihat hasilnya dalam report Gherkio. Tapi aku tidak menganggapnya sebagai pengganti k6. Gherkio belum memiliki traffic model, arrival rate, atau analisis performa sedalam tool load testing khusus.

Perubahan kecil yang terasa saat dipakai

Selain tiga fitur utama tadi, ada beberapa perubahan yang datang langsung dari penggunaan sehari-hari:

• save: menerima count(body.data). Response null atau array kosong disimpan sebagai 0.
• Helper trimPrefix, trimSuffix, dan split membersihkan value tanpa script tambahan.
• Directory multipart asset bisa diatur melalui assets.path.
• Variable dari examples dan composed scenario dikenali oleh static validation.
• Report menyimpan initial dan final variables, termasuk perubahan setelah repeat.
• Authorization header dan authToken dimasking di report dan generated cURL.
• Error saat membuat atau mengirim HTTP request benar-benar menggagalkan scenario. Sebelumnya ada transport error yang bisa menghasilkan false green.

Repository Gherkio juga sekarang memiliki executable feature catalog menggunakan mock environment. Contoh composition, multipart, collection matcher, repeat, helper, dan virtual user bisa dijalankan tanpa API eksternal:

gherkio validate
gherkio run --env mocked

Contoh Redis dan Sentinel tetap terpisah karena HTTP mock tidak bisa meniru protokol Redis.

Mencoba alpha.9

Versi ini bisa dijalankan langsung menggunakan Go:

go run github.com/muhfaris/[email protected] --version

Dokumentasi penggunaan ada di repository Gherkio. Perubahan lengkapnya ada di release v0.1.0-alpha.9. Aku juga menulis gambaran proyek dan batas desainnya di halaman project Gherkio.

Masih ada banyak hal yang bisa diperbaiki, terutama untuk load reporting dan workflow asynchronous yang lebih kompleks. Untuk alpha.9, targetku lebih sederhana: mengurangi bagian testing API yang sebelumnya masih harus diperiksa manual, tanpa mengubah Gherkio menjadi general-purpose scripting language.