Testing Your Apps

#references #programming #testing #ci-cd #devops

Pengujian memverifikasi perilaku aplikasi pada level berbeda sebelum perubahan sampai ke pengguna.

Unit menguji fungsi kecil secara terisolasi. Integrasi menguji sambungan modul, database, dan API. Sistem menguji aplikasi utuh.

Acceptance menguji kebutuhan bisnis dari sudut pengguna pada environment mirip produksi. Lihat jenis pengujian Atlassian.

Level pengujian

Unit memanggil kode langsung dan menilai output tanpa UI, service, atau database. Test ini murah, cepat, dan cocok dijalankan setiap perubahan.

Integrasi menguji pertukaran data antar komponen, misalnya model dengan database atau method dengan API. Lihat porsi integration pada piramida.

System test menilai aplikasi lengkap yang terintegrasi. Acceptance test menilai kesiapan rilis terhadap kriteria bisnis.

Batas antar level tidak selalu tegas. Satu test tergolong integrasi bila menyentuh modul lain, sistem eksternal, network, atau I/O file dan database.

Piramida pengujian

Piramida dari buku Mike Cohn menumpuk banyak unit test di dasar, sedikit integration di tengah, dan sedikit E2E di puncak.

Acuan umum adalah 70 persen unit, 20 persen integrasi, dan 10 persen E2E. Rasio tepat bergantung pada konteks proyek. Lihat strategi piramida CircleCI.

E2E meniru klik, ketik, dan alur pengguna pada browser atau perangkat nyata. Keyakinannya tertinggi, tetapi paling lambat dan paling flaky.

Cadangkan E2E untuk alur vital seperti login, checkout, dan pembayaran. Uji sisanya dengan test yang lebih cepat.

Test-driven development

TDD menulis satu test gagal, menulis kode minimal sampai hijau, lalu refactor. Siklus ini dikenal sebagai Red Green Refactor.

Proses selalu berangkat dari daftar test eksplisit. Urutan test dipilih agar desain penting lebih dulu terbentuk.

Berpikir tentang test lebih dulu memaksa interface dirancang sebelum implementasi. Lihat bliki TDD Fowler.

Langkah refactor wajib dijaga. Tanpa itu, kode hanya menjadi tumpukan fragmen yang kebetulan lolos test.

Behavior-driven development

BDD menutup jarak bisnis dan teknis lewat kolaborasi lintas peran, iterasi kecil, dan contoh konkret perilaku sistem.

Contoh yang disepakati menjadi dokumentasi hidup yang dicek otomatis terhadap perilaku aplikasi. Lihat definisi BDD Cucumber.

BDD tidak menggantikan proses agile yang ada. Ia berperan sebagai plugin yang memperkuat delivery bertahap.

Gunakan BDD untuk fitur lintas tim dengan aturan bisnis yang mudah disalahpahami. Lihat siklus TDD IBM sebagai pembanding ritme kerja.

Pengujian di CI

Pengujian CI mengotomatisasi build dan pemeriksaan pada setiap perubahan. Setiap tahap pipeline menjawab aman tidaknya perubahan untuk lanjut.

CI memvalidasi merge ke repo bersama. Delivery menjaga kode teruji selalu siap dirilis secara aman dan terprediksi. Lihat panduan CI Harness.

Strategi berlapis memberi keyakinan bertahap: unit, integrasi, regresi, E2E, performa, dan keamanan sebelum promosi ke produksi.

Test pipeline harus cepat, deterministik, dan terisolasi. Test yang berbagi state global, port, atau database menghasilkan gagal acak.

Memilih strategi

Mulai dari piramida untuk proporsi, TDD untuk urutan penulisan unit, BDD untuk kesepakatan contoh, dan CI untuk irama eksekusi.

Jalankan unit pada setiap commit, integrasi setelah merge besar, dan E2E pada milestone rilis. Proporsi dan frekuensi menyesuaikan biaya tiap lapisan.

Coverage menunjukkan kode yang tereksekusi, bukan kualitas assertion. Angka tinggi tetap dapat menyembunyikan test yang lemah.

Batasan

Halaman ASTQB tentang test level tidak dapat diambil karena consent wall, sehingga definisi formal ISTQB belum terverifikasi di sini.

Klaim produktivitas TDD dan BDD pada sumber ini bersifat laporan praktisi dan vendor, bukan uji terkontrol. Generalisasi lintas konteks perlu bukti tambahan.

Terkait

Sumber

Enter your search text in the box above

Select a result to preview