Strategi Regression Test untuk Target CPU dan OS yang Beragam

Strategi regression test untuk target CPU dan OS yang beragam diperlukan ketika aplikasi Anda tidak hanya berjalan di satu kombinasi mesin yang homogen. Munculnya perangkat Windows dengan CPU baru kembali mengingatkan bahwa asumsi lama seperti “kalau lolos di x86_64 maka aman di mana-mana” sering salah. Perbedaan arsitektur CPU, versi OS, scheduler, ABI, dan dependency native dapat memunculkan bug yang tidak terlihat pada lingkungan pengembangan utama.

Tujuan regression test lintas platform bukan menguji semua kombinasi tanpa batas, melainkan menemukan regresi dengan biaya yang masuk akal. Praktiknya adalah membangun matriks prioritas, memisahkan jenis pengujian berdasarkan risiko, menjalankan subset cepat di setiap perubahan, lalu menaruh pengujian mahal pada jalur yang lebih selektif seperti nightly build, release candidate, atau sebelum publish artifact.

Mengapa bug lintas CPU dan OS sering lolos

Banyak tim memiliki coverage unit test yang baik, tetapi tetap kebobolan saat aplikasi dijalankan pada arsitektur atau OS berbeda. Penyebabnya biasanya bukan logika bisnis murni, melainkan interaksi dengan detail sistem yang tidak tercakup oleh test biasa.

1. Race condition dan perilaku scheduler

Race condition sering tersembunyi karena urutan eksekusi thread pada mesin developer cenderung konsisten. Begitu dipindah ke CPU dengan karakteristik berbeda, jumlah core berbeda, atau scheduler OS berbeda, urutan tersebut berubah dan bug muncul.

• Test lulus di Linux x86_64 tetapi gagal sporadis di Windows ARM64.
• Deadlock hanya muncul pada mesin dengan core lebih banyak.
• Timeout yang terlalu ketat lulus di laptop cepat tetapi gagal di runner CI yang lebih lambat.

Masalah ini tidak selalu berarti platform tertentu buruk; sering kali test atau aplikasi memang menyimpan asumsi timing yang rapuh.

2. Asumsi endianness dan alignment

Bila aplikasi memproses binary protocol, file format, memory-mapped data, atau FFI/native binding, asumsi tentang representasi memori dapat menjadi sumber bug. Contoh umum:

• Meng-cast buffer byte langsung ke struct native tanpa mempertimbangkan alignment.
• Mengandalkan urutan byte host alih-alih melakukan konversi eksplisit.
• Menggunakan pointer aliasing atau akses unaligned yang kebetulan aman pada satu arsitektur tetapi tidak pada arsitektur lain.

Walaupun banyak target modern menggunakan little-endian, desain test yang benar tetap memverifikasi parsing dan serialisasi secara eksplisit, bukan mengandalkan kebetulan perilaku mesin host.

3. Perbedaan instruksi SIMD dan jalur optimisasi

Kode performa tinggi sering memiliki beberapa jalur: scalar fallback, SSE/AVX pada x86, NEON pada ARM, atau implementasi yang dipilih saat runtime. Regression test perlu memastikan semua jalur menghasilkan output identik. Bug sering muncul ketika:

• Implementasi SIMD menggunakan pembulatan berbeda dengan scalar path.
• Deteksi fitur CPU salah sehingga jalur yang tidak kompatibel tetap aktif.
• Compiler melakukan auto-vectorization yang mengubah asumsi numerik atau alignment.

Tanpa test yang memaksa fallback dan fast-path, Anda hanya menguji jalur yang kebetulan aktif di runner tertentu.

4. Timing, clock source, dan timeout

Perbedaan resolusi timer, monotonic clock, sleep granularity, dan beban sistem dapat membuat test sensitif timing menjadi flaky. Anti-pattern yang umum:

• Mengasumsikan operasi selesai dalam 50 ms.
• Menggunakan sleep sebagai sinkronisasi antar-thread.
• Membandingkan durasi absolut, bukan batas atas yang longgar atau properti perilaku.

Jika test Anda memverifikasi kebenaran, fokuskan pada hasil dan sinyal sinkronisasi yang deterministik. Jika harus menguji performa, pisahkan dari regression test fungsional.

5. Dependency native dan perbedaan ABI

Library native, driver, runtime embedding, dan binding C/C++ adalah sumber regresi paling umum dalam skenario lintas platform. Perbedaan yang sering terjadi meliputi:

• Nama file library dan mekanisme loading berbeda per OS.
• Perbedaan calling convention atau ukuran tipe data native.
• Perbedaan perilaku filesystem, path separator, line ending, locale, atau encoding default.
• Paket dependency tersedia di x86_64 tetapi belum stabil di ARM64 atau versi OS tertentu.

Di sinilah contract test untuk komponen native menjadi penting, karena unit test level aplikasi sering terlalu tinggi untuk menangkap mismatch ABI atau perilaku library.

Menyusun matriks prioritas pengujian

Kesalahan terbesar adalah mencoba menguji semua kombinasi CPU, OS, dan versi runtime pada setiap commit. Biaya akan meledak, antrean CI memanjang, dan tim mulai mengabaikan hasil test. Solusi yang lebih efektif adalah membuat matriks prioritas berdasarkan risiko bisnis dan teknis.

Prinsip penentuan prioritas

• Tingkat penggunaan: platform yang paling banyak dipakai user harus diuji paling sering.
• Tingkat perubahan: kombinasi yang paling sering berubah, misalnya OS baru atau CPU baru, perlu cakupan tambahan.
• Tingkat risiko teknis: target dengan dependency native, SIMD, atau concurrency tinggi lebih rawan.
• Biaya eksekusi: target mahal tetap diuji, tetapi tidak harus pada semua pull request.

Contoh matriks prioritas

Berikut contoh sederhana yang bisa diadaptasi:

Intinya, satu kombinasi dijadikan baseline gate untuk kecepatan, lalu kombinasi lain dipilih sebagai risk gate untuk menangkap bug spesifik platform.

Gunakan istilah seperti tier-1, tier-2, dan tier-3 agar kebijakan CI jelas. Tier-1 wajib hijau untuk merge. Tier-2 boleh dijalankan paralel atau pasca-merge. Tier-3 cocok untuk nightly atau menjelang rilis.

Test pyramid yang sadar platform

Regression test lintas CPU/OS efektif jika dibangun dengan test pyramid yang tepat. Jangan memindahkan semua beban ke end-to-end test. Semakin tinggi level test, semakin mahal dan semakin sulit mendiagnosis regresi spesifik platform.

Lapisan 1: Unit test portable

Mayoritas logika tetap diuji di level unit. Fokus pada:

• Parsing/serialisasi dengan konversi endianness eksplisit.
• Boundary value untuk integer, floating-point, dan overflow.
• Jalur scalar fallback yang tidak bergantung pada fitur CPU tertentu.
• Determinisme algoritma tanpa mengandalkan urutan thread.

Unit test sebaiknya dapat berjalan cepat pada semua runner baseline. Jika ada fitur SIMD/runtime dispatch, sediakan cara untuk memaksa mode tertentu melalui flag lingkungan, dependency injection, atau build-time toggle.

Lapisan 2: Integration test lintas sistem

Di level ini Anda menguji interaksi dengan OS, filesystem, network stack, runtime, dan dependency native. Contoh:

• Membuka file dengan path Unicode dan separator berbeda.
• Memuat library native dan memanggil fungsi utama.
• Menguji thread pool atau async pipeline dengan beban realistis namun terbatas.
• Mengonfirmasi fallback berjalan ketika fitur CPU tidak tersedia.

Integration test adalah tempat banyak bug lintas OS muncul. Simpan cakupannya pada skenario inti yang benar-benar mewakili risiko, bukan mencoba menyalin semua unit test ke level ini.

Lapisan 3: Smoke test pasca-build

Setelah artifact dibangun untuk target tertentu, jalankan smoke test singkat untuk memastikan binary benar-benar dapat dijalankan pada target tersebut. Ini sangat berguna untuk package installer, CLI, daemon, atau library dengan komponen native.

Smoke test pasca-build biasanya memverifikasi:

• Binary bisa dijalankan tanpa crash.
• Versi dan metadata build terbaca.
• Startup path berhasil memuat dependency native.
• Operasi dasar seperti parse config, baca file kecil, atau satu request lokal berhasil.

Karena murah dan cepat, smoke test layak dijalankan pada lebih banyak kombinasi platform dibanding integration test penuh.

Lapisan 4: Compatibility dan release validation

Untuk target CPU/OS berisiko tinggi, sediakan suite kecil sebelum rilis:

• Contract test komponen native.
• Subset test performa fungsional untuk memastikan tidak ada fallback yang salah.
• Verifikasi packaging, installer, signing, atau bundle dependency.

Suite ini tidak harus berjalan pada setiap commit, tetapi wajib sebelum publish release.

Contract test untuk komponen native

Jika aplikasi memiliki binding ke C/C++, Rust, Go, Swift, atau library sistem lain, buat contract test yang memverifikasi antarmuka lintas bahasa/platform secara eksplisit. Tujuannya bukan hanya memeriksa hasil akhir, tetapi memastikan kontrak ABI dan perilaku dasar tetap konsisten.

Apa yang harus diuji

• Ukuran dan layout data bila struktur dikirim melintasi boundary native.
• Konversi string dan encoding, termasuk null-termination jika relevan.
• Kepemilikan memori: siapa yang mengalokasikan dan membebaskan.
• Kode error dan pemetaan exception/error antar runtime.
• Thread-safety jika fungsi native dipanggil paralel.

Contoh pendekatan contract test

Misalnya aplikasi memanggil fungsi native untuk kompresi atau hashing. Buat test yang memverifikasi:

• Input kosong, kecil, besar, dan data acak menghasilkan output yang sama di semua target.
• Buffer unaligned tetap diproses aman bila API mengizinkan.
• API gagal dengan kode error yang sama untuk input tidak valid.
• Resource dibersihkan tanpa memory leak atau double free.

Jika memungkinkan, jalankan contract test terhadap dua mode: implementasi reference/scalar dan implementasi optimized/native. Ini membantu menemukan perbedaan hasil yang tersembunyi di jalur SIMD atau target CPU tertentu.

# contoh pseudo-command dalam CI untuk memaksa mode implementasi berbeda
APP_FORCE_SCALAR=1 ./bin/app-selftest
APP_FORCE_NATIVE=1 ./bin/app-selftest

Nama environment variable tentu bergantung pada aplikasi Anda; prinsipnya adalah menyediakan switch eksplisit untuk memilih jalur yang ingin diuji.

Mendeteksi flaky test di CI

Flaky test adalah musuh utama regression test lintas platform. Ia merusak kepercayaan tim terhadap CI dan menutupi regresi nyata. Pada kombinasi CPU dan OS yang lebih beragam, flaky test hampir selalu meningkat jika tidak ditangani sistematis.

Tanda test mulai flaky

• Gagal hanya pada retry kedua atau ketiga.
• Gagal pada satu OS tetapi tidak bisa direproduksi lokal.
• Gagal saat runner sibuk atau paralelisme tinggi.
• Pesan error berkisar pada timeout, race, resource busy, atau order-dependent assertion.

Praktik deteksi yang efektif

1. Simpan histori hasil test per nama test dan platform. Jangan hanya melihat status job agregat.
2. Tandai test dengan failure rate berulang, misalnya gagal sporadis di platform yang sama.
3. Pisahkan kategori “known flaky” sementara dengan tiket perbaikan dan SLA, bukan dibiarkan permanen.
4. Jalankan rerun terbatas untuk diagnosis, bukan untuk menyembunyikan bug. Jika rerun diperlukan, laporkan status flaky secara eksplisit.
5. Log metadata lingkungan: CPU architecture, OS version, compiler/runtime, jumlah core, dan fitur yang aktif.

Penyebab flaky test yang umum dan perbaikannya

• Timeout terlalu ketat → gunakan sinkronisasi berbasis event/condition variable, bukan sleep statis.
• Berbagi state global → isolasi resource sementara, port, direktori, dan environment variable.
• Asersi pada urutan yang tidak dijamin → urutkan hasil sebelum dibandingkan jika urutan memang bukan kontrak.
• Ketergantungan pada waktu lokal/locale → pakai timezone dan locale eksplisit.
• Konkurensi → tambahkan stress test terpisah yang sengaja memaksa interleaving tinggi.

Jangan menambal flaky test dengan retry tanpa observabilitas. Retry boleh dipakai sementara untuk mengurangi kebisingan, tetapi CI harus tetap mencatat bahwa test tersebut tidak stabil.

Workflow CI yang efisien agar biaya tetap terkendali

Kunci efisiensi adalah membedakan jalur cepat untuk feedback developer dan jalur luas untuk mitigasi risiko platform. Anda tidak perlu menjalankan seluruh matriks pada semua event.

Pembagian workflow yang disarankan

• Pull request cepat: baseline Linux x86_64 + unit test penuh + smoke test artifact utama.
• Pull request berisiko: tambah Windows dan satu target ARM jika file yang berubah menyentuh native code, concurrency, build script, atau packaging.
• Post-merge / nightly: jalankan matriks lebih luas termasuk target CPU/OS sekunder.
• Release candidate: jalankan suite kompatibilitas, contract test native, smoke test semua artifact, dan verifikasi packaging.

Heuristik pemicu yang praktis

Gunakan pemetaan perubahan file ke level pengujian:

• Perubahan di src/core, native/, atau ffi/ → aktifkan matrix lintas OS/arsitektur.
• Perubahan dokumentasi atau UI non-native → cukup baseline cepat.
• Perubahan build system, dependency lockfile, Dockerfile, installer → jalankan smoke test lebih luas.

Dengan cara ini, biaya CI mengikuti tingkat risiko perubahan, bukan sekadar jumlah commit.

Contoh workflow GitHub Actions yang efisien

Contoh berikut menunjukkan pola umum: job baseline untuk semua PR, job extended matrix hanya untuk event tertentu atau perubahan berisiko, serta smoke test pasca-build. Nama script dan target dapat disesuaikan dengan proyek Anda.

name: regression

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'

jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      low_level_changed: ${{ steps.filter.outputs.low_level_changed }}
    steps:
      - uses: actions/checkout@v4
      - id: filter
        uses: dorny/paths-filter@v3
        with:
          filters: |
            low_level_changed:
              - 'src/core/**'
              - 'native/**'
              - 'ffi/**'
              - '.github/workflows/**'
              - 'build/**'

  baseline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup
        run: ./ci/setup.sh
      - name: Unit tests
        run: ./ci/test-unit.sh
      - name: Build
        run: ./ci/build.sh
      - name: Smoke test
        run: ./ci/smoke.sh ./dist/app

  extended-matrix:
    needs: changes
    if: github.event_name == 'schedule' || github.ref == 'refs/heads/main' || needs.changes.outputs.low_level_changed == 'true'
    strategy:
      fail-fast: false
      matrix:
        include:
          - os: windows-latest
            target: x86_64
          - os: macos-latest
            target: arm64
          - os: ubuntu-latest
            target: arm64
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - name: Setup
        run: ./ci/setup.sh
      - name: Build
        run: ./ci/build.sh --target ${{ matrix.target }}
      - name: Integration tests
        run: ./ci/test-integration.sh
      - name: Native contract tests
        run: ./ci/test-contract-native.sh
      - name: Smoke test
        run: ./ci/smoke.sh ./dist/app

Beberapa catatan penting:

• fail-fast: false membantu Anda melihat seluruh pola kegagalan lintas platform dalam satu run.
• Job perubahan file mencegah matriks mahal berjalan untuk perubahan berisiko rendah.
• Smoke test di semua job build cepat tetapi bernilai tinggi untuk mendeteksi artifact rusak.
• Nightly schedule cocok untuk target mahal atau langka yang tidak perlu memblokir semua PR.

Strategi penghematan biaya tambahan

• Cache dependency dan toolchain bila aman.
• Bangun ulang hanya artifact yang terdampak.
• Pisahkan test deterministik cepat dari test stres/konkurensi mahal.
• Gunakan self-hosted runner hanya jika workload stabil dan biaya operasional memang lebih rendah.
• Untuk target langka, pertimbangkan subset representatif daripada seluruh suite.

Smoke test pasca-build yang sebaiknya selalu ada

Smoke test sering dianggap remeh, padahal untuk regresi lintas CPU/OS justru paling murah dan paling cepat memberi sinyal. Sebuah binary bisa lulus kompilasi tetapi gagal start karena dependency native hilang, arsitektur artifact salah, atau path loader berbeda.

Checklist smoke test

• Jalankan --version atau command identitas serupa.
• Baca file konfigurasi minimal dan parse tanpa error.
• Lakukan operasi inti satu kali dengan fixture kecil.
• Pastikan exit code sesuai.
• Verifikasi log awal tidak mengandung error loading dependency.

Untuk service, smoke test dapat berupa startup singkat, health check lokal, lalu shutdown bersih. Untuk library, sediakan executable self-test kecil yang memanggil API paling kritis.

Kesalahan umum dalam regression test lintas platform

• Menganggap emulator setara perangkat nyata. Emulator berguna, tetapi tidak selalu mewakili performa, alignment, atau perilaku scheduler asli.
• Hanya menguji jalur tercepat. Pastikan fallback path dan mode tanpa SIMD juga diuji.
• Mengunci timeout terlalu agresif. Ini menciptakan flaky test, bukan kualitas.
• Tidak mencatat metadata platform saat gagal. Tanpa informasi ini, bug lintas CPU sulit direproduksi.
• Menaruh semua verifikasi pada release stage. Akibatnya regresi diketahui terlalu lambat dan biaya perbaikannya tinggi.

Panduan implementasi bertahap

Jika saat ini CI Anda baru menguji satu platform, jangan langsung membangun matriks besar. Mulailah bertahap:

1. Tetapkan satu baseline cepat sebagai gate utama.
2. Tambahkan smoke test pasca-build untuk semua artifact.
3. Identifikasi area rawan: native dependency, concurrency, SIMD, parsing binary.
4. Buat contract test untuk boundary native.
5. Tambahkan satu atau dua target berisiko tinggi di nightly.
6. Kumpulkan data flaky test dan failure pattern per platform.
7. Naikkan target tertentu menjadi gate release jika failure-nya sering dan berdampak ke user.

Pendekatan ini lebih realistis daripada mengejar coverage platform maksimal sejak awal.

Penutup

Strategi regression test untuk target CPU dan OS yang beragam yang efektif bukan soal jumlah kombinasi terbanyak, melainkan soal penempatan verifikasi yang tepat. Gunakan baseline cepat untuk menjaga produktivitas, matriks prioritas untuk mengarahkan biaya ke area berisiko, smoke test untuk menangkap artifact rusak lebih awal, contract test untuk boundary native, dan observabilitas CI untuk mengendalikan flaky test.

Ketika ekosistem hardware dan OS terus berubah—termasuk munculnya Windows pada CPU generasi dan arsitektur baru—workflow verifikasi lintas platform bukan lagi tambahan opsional. Ia adalah bagian dari desain kualitas aplikasi itu sendiri.