Belajar Tailwind CSS - Testing, Observability & Monitoring

#Pendahuluan

Utility class yang salah bisa merusak tampilan tanpa error apa pun — tidak ada exception, tidak ada test yang gagal, hanya pixel yang bergeser. Episode 20 membahas cara menangkap regresi semacam ini: visual regression testing, pemantauan performa, dan gerbang kualitas di CI.

Karena UI berbasis utility sulit diuji dengan assertion biasa, strateginya bergeser ke perbandingan visual dan metrik objektif: screenshot yang dibandingkan pixel demi pixel, budget ukuran CSS, dan metrik Web Vitals yang dipantau terus-menerus.

#Visual Regression Testing

#Playwright Snapshots

Playwright bisa mengambil screenshot lalu membandingkannya dengan baseline:

Snapshot dengan Playwright

import { test, expect } from "@playwright/test";
 
test("halaman utama tidak berubah", async ({ page }) => {
  await page.goto("/");
  await expect(page).toHaveScreenshot("home.png", { maxDiffPixelRatio: 0.02 });
});

toHaveScreenshot menyimpan gambar pertama sebagai baseline, lalu membandingkan pada run berikutnya. maxDiffPixelRatio: 0.02 memberi toleransi dua persen pixel berbeda — cukup untuk menekan noise kecil tanpa melewatkan regresi nyata.

#Chromatic untuk Storybook

Untuk komponen yang sudah punya stories di episode 19, Chromatic membandingkan tangkapan Storybook di cloud. Setiap perubahan class akan muncul sebagai diff visual yang bisa di-review per pixel — alur yang sangat cocok untuk library komponen.

Perlu diingat: pengujian visual hanya sekuat baseline-nya. Baseline yang basi — misalnya tidak diperbarui setelah redesign besar — akan membuat seluruh tim mengejar diff yang menyesatkan. Perbarui baseline secara sadar pada commit yang memang mengubah tampilan, bukan secara otomatis pada setiap run.

#Performance Monitoring

#Lighthouse dan Web Vitals

Lighthouse mengaudit performa, aksesibilitas, dan praktik terbaik:

npx lighthouse https://example.com --output=html --output-path=report.html

Perhatikan metrik yang terpengaruh CSS: LCP (waktu elemen terbesar terlihat — dipengaruhi CSS render-blocking), CLS (pergeseran layout — dipengaruhi font dan gambar tanpa dimensi), dan TBT (total blocking time). Untuk memantau terus-menerus, Lighthouse CI menjalankan audit pada setiap commit.

#Budget di Webpack dan Vite

Atur budget ukuran CSS langsung di bundler:

Budget performa di Vite

export default {
  build: {
    cssCodeSplit: true,
    chunkSizeWarningLimit: 300,
  },
};

Dan untuk audit skala penuh, pasang Lighthouse CI:

ci:
  budget:
    - path: "/*"
      resourceSizes:
        stylesheet: 100

stylesheet: 100 artinya total CSS per halaman maksimal 100KB — melebihi angka ini, CI gagal.

#Error-flooring CSS Regressions di CI

Gabungkan tiga gerbang ke dalam pipeline agar regresi CSS tertangkap sebelum produksi:

1. Unit test — snapshot class CVA dan assertion toHaveClass dari episode 15.
2. Visual test — screenshot Playwright atau Chromatic untuk komponen kritis.
3. Budget check — ukuran CSS dan metrik Lighthouse dibandingkan dengan ambang.

Contoh step CI yang memeriksa ukuran CSS:

size=$(wc -c < dist/output.css)
if [ "$size" -gt 102400 ]; then
  echo "CSS terlalu besar: $size bytes" >&2
  exit 1
fi

wc -c < dist/output.css menghitung byte file CSS, dan script menggagalkan pipeline bila melewati 100KB. Ini floor error yang murah — setiap PR yang membengkak langsung terlihat.

#Penutup

Episode 20 melengkapi gerbang kualitas: visual regression testing dengan Playwright dan Chromatic, pemantauan performa dengan Lighthouse dan Web Vitals, serta budget dan pemeriksaan otomatis yang mencegah regresi CSS masuk ke CI.

Inti yang harus dibawa pulang:

• Screenshot snapshot menangkap regresi visual tanpa error.
• Chromatic membandingkan tangkapan Storybook di cloud.
• LCP, CLS, dan TBT adalah metrik yang paling dipengaruhi CSS.
• Lighthouse CI menjalankan audit pada tiap commit.
• Budget stylesheet bisa ditegakkan di bundler dan CI.
• Kombinasi unit, visual, dan budget menciptakan floor regresi yang kuat.

Di episode 21 selanjutnya kita akan membahas migration strategies & large-scale refactors — teknik migrasi incremental dari CSS tradisional, pertimbangan monorepo untuk berbagi config dan token, serta strategi rollback dan pengujian kompatibilitas.