DiffsHub membantu QA dan tim pengembang mengenali test yang rentan menjadi flaky atau gagal setelah commit terbaru dengan menganalisis perubahan kode secara spesifik. Dengan mengirimkan diff dari branch fitur ke DiffsHub, tim bisa melihat hotspot unstable test, menyusun ulang rerun selektif, dan menunda release sampai kerentanan regresi teridentifikasi dan diperbaiki.

Artikel ini menjelaskan workflow verifikasi berbasis diff, teknik menentukan hotspot test, langkah rerun selektif, dan cara memperkaya pelaporan CI/CD agar investigasi regresi menjadi lebih terarah.

Workflow Verifikasi Berbasis Diff

Workflow ini dijalankan di pipeline PR/CI setiap kali ada commit baru. Tujuannya adalah menyaring hanya tes yang diprediksi terdampak oleh perubahan kode, sehingga mencegah flaky test melewati pengujian utama.

  1. Ekstraksi diff relevan: Ambil daftar file yang berubah dari branch fitur terhadap base branch, seperti main atau release. Gunakan git diff --name-only origin/main...HEAD untuk memperoleh lintasan file.
  2. Kirim diff dan metadata ke DiffsHub: Paketkan diff bersama informasi commit, coverage terbaru, dan daftar test yang pernah gagal. DiffsHub akan menggabungkan informasi ini dengan basis data historis untuk menilai flaky test potensial.
  3. Terima output DiffsHub: Respons biasanya memuat daftar test yang paling mungkin gagal akibat perubahan (contoh: test kelas tertentu, integrasi, atau e2e scenario). Laporkan summary ini ke tahap QA dan buat trigger rerun selektif.
  4. Ambil keputusan berdasarkan analisis: Jika DiffsHub menunjukkan regresi tinggi, pertimbangkan menahan merge atau memicu job verifikasi tambahan untuk test kritikal.

Berikut contoh fragmen pipeline yang menyiapkan diff dan menyerahkannya ke sistem monitoring (gunakan endpoint sesuai dokumentasi DiffsHub):

# buat diff patch
mkdir -p ci-artifacts
git fetch origin main --depth=1
git diff origin/main...HEAD > ci-artifacts/diff.patch

# kirim ke DiffsHub (ganti URL/param sesuai dokumentasi resmi)
curl -H "Authorization: Bearer $DIFFSHUB_API_KEY" \
     -F "diff=@ci-artifacts/diff.patch" \
     -F "commit=$CI_COMMIT_SHA" \
     "$DIFFSHUB_ENDPOINT/analyze" \
     -o ci-artifacts/diffshub-response.json

File diffshub-response.json dapat dimanfaatkan untuk memicu rerun dan menyisipkan laporan ke PR.

Menentukan Hotspot Unstable Test

Output DiffsHub biasanya menandai hotspot berdasarkan korelasi antara file yang berubah dan log histori flaky test. Untuk setiap file atau directory yang diubah, Anda dapat meninjau daftar test yang diprediksi terdampak.

Perhatikan dua hal berikut:

  • Coverage diff-aware: DiffsHub menggabungkan coverage runtime dengan diff file. Area kode dengan coverage tinggi tetapi banyak perubahan mendapatkan prioritas rerun.
  • Rekaman unstable test: Bila DiffsHub menyarankan sebuah test, kenali apakah test itu sudah pernah flaky di pipeline lain. Gunakan flag ini untuk memutuskan melakukan rerun deterministik.

Tim QA dapat menambahkan informasi ini ke dashboard issue/PR:

  • Tag PR dengan label seperti needs-flaky-investigation.
  • Gunakan daftar test dari DiffsHub untuk memutuskan apakah perlu tambahan instrumentation atau simulasi environment.

Rerun Selektif Berdasarkan Analisis

Setelah menerima daftar test dari DiffsHub, Anda bisa menjalankan rerun selektif alih-alih entire suite. Contoh implementasi sederhana dengan shell:

unstable_tests=$(jq -r '.unstable_tests[]' ci-artifacts/diffshub-response.json)
for test in $unstable_tests; do
  echo "Menjalankan ulang $test"
  ./gradlew test --tests "$test" || {
    echo "Test $test tetap gagal, hentikan pipeline"
    exit 1
  }
done

Jika rerun selektif masih gagal, hasilnya bisa langsung ditandai sebagai regresi dan dilengkapi dengan rekaman log dari DiffsHub untuk memudahkan debugging.

Tambahkan juga mekanisme retry limit, misalnya rerun maksimal dua kali untuk test yang ditandai flaky sehingga pipeline tidak terjebak dalam rerun tanpa batas.

Memperkaya Pelaporan CI/CD

Integrasi DiffsHub tidak hanya soal rerun. Gunakan data pengaruh diff untuk memperkaya laporan di CI/CD:

  • Tambahkan status summary ke PR: misalnya "DiffsHub memprediksi 3 test beresiko" dengan tautan ke dashboard DiffsHub.
  • Gunakan badge di pipeline untuk menandai "Hotspot Regression" jika perubahan menyentuh area kritikal.
  • Gabungkan hasil rerun selektif dan analisis DiffsHub ke log build agar QA/dev bisa menelusuri hasil sebelum merge.

Dengan informasi ini QA bisa memprioritaskan manual testing atau review tambahan berdasarkan diff yang dideteksi sebagai risikon tinggi.

Pertimbangan, Limitasi, dan Tips Debugging

Meskipun DiffsHub memperkaya observabilitas, perhatikan hal berikut:

  • Kualitas data historis: Analisis hanya dapat akurat jika riwayat flaky test sudah lengkap. Pastikan pipeline melaporkan hasil test lama ke DiffsHub.
  • False positive: Tidak semua test yang berubah akibat diff adalah regression nyata. Gunakan rerun selektif untuk memvalidasi dan jangan langsung blok merge tanpa verifikasi.
  • Timeout atau environment: Flaky test bisa disebabkan oleh environment, bukan diff. Laporkan metadata environment (OS, dependency) ke DiffsHub agar korelasi lebih kuat.

Debugging tip: setelah rerun selektif gagal, tidak hanya lihat log test, tetapi juga file diff yang memicu analisis, lalu rekonstruksi scenario lokal. Jika DiffsHub menyediakan heatmap coverage, gunakan untuk mengecek apakah branch/test environment sama.

Penutup

Dengan memanfaatkan workflow berbasis diff di DiffsHub, tim QA/dev dapat mengidentifikasi flaky test dan regresi sebelum rilis, mengurangi kepanikan saat release candidate dibuild. Kunci keberhasilan adalah menyambungkan analisis diff ke rerun selektif, memperkaya laporan CI/CD, dan selalu menyesuaikan threshold agar workflow tetap responsif terhadap kode yang paling rawan.