Belajar Jest - Running Jest in CI/CD

#Pendahuluan

Test yang hanya berjalan di laptop developer tidak cukup. Episode 14 membahas running Jest in CI/CD — menjalankan suite otomatis di setiap push dan pull request. Kalian akan mengintegrasikan Jest ke GitHub Actions, GitLab CI, dan Jenkins, memanfaatkan eksekusi paralel dan test splitting, menerapkan fail fast dengan selective test runs, serta mempublikasikan hasil dan coverage badges.

Pipeline yang baik menjadikan test sebagai gerbang kualitas otomatis: kode yang gagal test tidak pernah mencapai produksi tanpa disadari.

#Integrasi Jest ke CI/CD

#GitHub Actions

Workflow paling sederhana untuk GitHub Actions:

name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

Baris npm ci menginstall dependency secara deterministik memakai lockfile — lebih andal daripada npm install di CI. Jika ada test yang gagal, job berhenti dan pull request ditandai merah.

#GitLab CI dan Jenkins

Untuk GitLab CI, tulis job di .gitlab-ci.yml dengan image Node.js dan jalankan npm ci lalu npm test. Jenkins memakai Jenkinsfile dengan stage test yang menjalankan perintah yang sama. Prinsipnya identik: environment bersih, dependency deterministik, dan satu perintah untuk seluruh suite.

#Parallel Test Execution dan Test Splitting

#Memanfaatkan Banyak Runner

Jest sudah berjalan paralel di dalam satu runner. Untuk suite sangat besar, kalian bisa membagi pekerjaan ke beberapa job CI:

npx jest --listTests --json > tests.json

npx jest --listTests --json menghasilkan daftar file test dalam JSON. Dari daftar ini, script CI bisa membagi file ke beberapa job — misalnya job pertama menangani separuh pertama, job kedua separuh berikutnya.

#Test Splitting dengan Shard

Beberapa penyedia CI menyediakan indeks shard. Pola umumnya:

matrix:
  shard: [1, 2, 3, 4]
steps:
  - run: npx jest --shard=${{ matrix.shard }}/4

Flag --shard=n/m memakai dukungan bawaan Jest untuk membagi test ke m bagian dan menjalankan bagian ke-n. Setiap job CI menangani sepertinya, dan total waktu pipeline menyusut drastis.

#Fail Fast dan Selective Test Runs

#Menjalankan Hanya Test yang Terdampak

Untuk feedback yang lebih cepat, jalankan test secara selektif berdasarkan perubahan. Di GitHub Actions, pakai paths di trigger, atau bandingkan perubahan dengan branch utama:

on:
  pull_request:
    paths:
      - "src/**"
      - "package.json"

Trigger paths membuat workflow hanya berjalan saat kode sumber berubah — dokumentasi, README, dan gambar tidak memicu suite penuh. Untuk fail fast, jalankan unit test terlebih dahulu; hanya lanjut ke langkah berat seperti e2e jika unit test lolos.

#Reporting Test Results dan Coverage Badges

#Mengunggah Laporan dan Coverage

Jest bisa menulis hasil dalam format JUnit yang dipahami hampir semua CI:

npx jest --coverage --reporters=default --reporters=jest-junit

Flag --reporters=jest-junit menulis hasil ke format JUnit setelah menginstall paket jest-junit. Laporan ini bisa diunggah sebagai artefak dan ditampilkan di ringkasan pipeline.

#Badge Coverage di README

Dari laporan coverage, banyak layanan seperti Coveralls atau Codecov membuat badge otomatis:

npm install --save-dev @vitest/coverage-v8

Jangan bingung — untuk Jest, pilih provider yang sesuai seperti @vitest/coverage-v8 hanya jika kalian sudah berpindah ke Vitest. Untuk Jest, gunakan collectCoverage dan unggah laporan lcov.info ke layanan badge. Pokoknya: laporan coverage di-publish setiap rilis, dan badge ditampilkan di README sebagai indikator tren kualitas.

#Penutup

Episode 14 membawa Jest ke pipeline CI/CD: setup di GitHub Actions, GitLab CI, dan Jenkins, eksekusi paralel dengan test splitting via shard, fail fast dengan selective test runs, serta pelaporan hasil dan coverage badges.

Inti yang harus dibawa pulang:

• Gunakan npm ci di CI agar dependency deterministik.
• Workflow dasar: checkout, setup Node, install, lalu npm test.
• --shard=n/m membagi test ke beberapa job paralel.
• Trigger paths memicu suite hanya saat kode relevan berubah.
• --reporters=jest-junit menghasilkan laporan yang bisa diunggah.
• Publikasikan coverage secara berkala dan tampilkan badge tren.

Di episode 15 selanjutnya kita akan membahas performance optimization — mempercepat eksekusi dengan watch mode dan caching, mengatur worker dengan --runInBand dan --maxWorkers, mengurangi setup overhead, serta mengoptimalkan test suite yang besar.