Belajar Selenium - Real-world Use Cases & Patterns

#Pendahuluan

Semua keterampilan dari episode 0 sampai 19 kini dipertemukan. Episode 20 membangun real-world use cases yang menggabungkan semuanya: login flow, e-commerce checkout, dan interaksi dashboard — lengkap dengan pola desain test yang layak ditiru. Ini adalah episode paling praktis dalam series.

Di sinilah kalian melihat bagaimana konsep saling bekerja sama dalam satu suite utuh: page object untuk struktur, waits untuk timing, data-driven untuk variasi, API helper untuk kecepatan, dan screenshot untuk bukti kegagalan. Setiap contoh adalah templat yang bisa kalian adaptasi ke aplikasi sendiri.

#Use Case: Login Flow

#Test Login dengan Page Object dan Data

Login adalah fondasi hampir semua aplikasi. Gunakan page object dari episode 6 dan data dari episode 9:

Test login flow lengkap

from pages.login_page import LoginPage
 
 
@pytest.mark.parametrize(
    "email,password,harapan",
    [
        ("user@example.com", "rahasia123", "Dashboard"),
        ("salah@example.com", "salah", "Kredensial tidak valid"),
    ],
)
def test_login_flow(email, password, harapan):
    driver.get("https://app.example.com/login")
    halaman = LoginPage(driver)
    halaman.isi_email(email)
    halaman.isi_password(password)
    halaman.klik_masuk()
 
    if harapan == "Dashboard":
        assert "Dashboard" in driver.title
    else:
        assert "Kredensial tidak valid" in halaman.pesan_error()

test_login_flow menggabungkan dua skenario dalam satu test berparameter: login sukses dan login gagal. Page object menyembunyikan detail locator, dan assertion dibedakan berdasarkan hasil yang diharapkan.

#Use Case: E-Commerce Checkout

#Alur Checkout yang Menyentuh Banyak Halaman

Checkout adalah flow bernilai bisnis tertinggi — di sinilah uang berpindah. Test-nya melintasi beberapa halaman dan memverifikasi setiap transisi:

Alur checkout penuh

from pages.produk_page import ProdukPage
from pages.keranjang_page import KeranjangPage
from pages.checkout_page import CheckoutPage
 
 
def test_checkout_berhasil():
    produk = ProdukPage(driver)
    produk.buka("https://app.example.com/produk/1")
    produk.tambah_ke_keranjang()
 
    keranjang = KeranjangPage(driver)
    keranjang.lanjutkan()
 
    checkout = CheckoutPage(driver)
    checkout.isi_alamat("Jl. Merdeka 1")
    checkout.pilih_pengiriman_standar()
    checkout.bayar()
 
    assert "Terima kasih" in checkout.konfirmasi()
    assert "Transaksi" in driver.current_url

test_checkout_berhasil memakai tiga page object yang berantai. Setiap halaman menangani elemennya sendiri, sementara test menceritakan alur bisnis secara linear — dari produk, ke keranjang, ke checkout, hingga konfirmasi.

#Memverifikasi Efek Samping

Untuk flow uang, validasi juga di sisi service layer seperti episode 16:

Verifikasi pesanan di backend

pesanan = requests.get(
    f"https://app.example.com/api/pesanan/{id}",
    timeout=5,
).json()
assert pesanan["status"] == "PAID"

pesanan["status"] == "PAID" membuktikan transaksi tercatat, bukan hanya tampilan berubah. Untuk flow kritis bisnis, verifikasi lintas lapisan ini bukan pilihan — ini keharusan.

#Use Case: Dashboard Interactions

#Dashboard yang Dinamis

Dashboard penuh dengan grafik dan angka yang muncul async. Test harus menunggu data benar-benar tampil sebelum meng-assert:

Test dashboard dengan wait data

wait = WebDriverWait(driver, 20)
wait.until(EC.text_to_be_present_in_element(
    (By.ID, "ringkasan-penjualan"), "Rp"
))
 
nilai = driver.find_element("id", "total-penjualan").text
assert int(nilai.replace(".", "").replace("Rp ", "")) > 0

wait.until(EC.text_to_be_present_in_element(...)) menunggu angka penjualan muncul — menghindari assertion terhadap dashboard yang masih kosong. Ini adalah pola khas dashboard: tunggu data, lalu validasi nilainya.

#Test Design Patterns untuk E2E Automation

#Pola yang Sudah Terbukti

Ringkasan pola yang kalian pakai sepanjang series, sekarang dalam satu daftar:

• Page Object Model (episode 6): halaman sebagai class.
• Fixture driver (episode 2): setup dan teardown terjamin.
• Explicit wait (episode 5): menunggu kondisi, bukan menebak waktu.
• Data-driven (episode 9): satu test, banyak kasus.
• API setup (episode 16): melewati UI yang lambat.

fixture driver + page object + wait eksplisit + data + bukti screenshot

fixture driver + page object + wait eksplisit + data + bukti screenshot adalah resep test E2E yang stabil dan mudah dipelihara. Semua bahan sudah kalian kuasai di episode-episode sebelumnya.

#Component-level vs Full UI Test

#Kapan Masing-masing

Tidak semua test harus menjalankan seluruh aplikasi. Bedakan dua level:

• Component-level test: menguji satu komponen (misalnya keranjang) di dalam aplikasi atau halaman khusus. Lebih cepat dan lebih fokus.
• Full UI test: menguji alur lengkap melintasi banyak halaman. Lebih mahal tapi memvalidasi integrasi nyata.

banyak component-level -> sedang full UI -> sedikit smoke (kritis)

banyak component-level -> sedang full UI -> sedikit smoke (kritis) mencerminkan piramida dari episode 0: lebih banyak test cepat yang fokus, sedikit test mahal untuk alur kritis.

#Memprioritaskan Test untuk Business-Critical Flows

#Menentukan Prioritas dengan Risiko

Alokasikan usaha test berdasarkan risiko bisnis, bukan kemudahan menulis:

• Tier 1 (smoke): login, checkout, pembayaran — harus selalu hijau, dijalankan di setiap commit.
• Tier 2 (fungsional): pencarian, filter, manajemen akun — dijalankan per merge.
• Tier 3 (mendalam): laporan, admin, edge case — dijalankan berkala.

Menandai tier dengan marker pytest

@pytest.mark.tier1
def test_checkout_berhasil():
    ...

@pytest.mark.tier1 menandai test kritis. Jalankan per tier sesuai jadwal: pytest -m tier1 di setiap commit, pytest -m "not tier3" di setiap merge. Prioritas ini menjaga pipeline cepat sementara flow kritis selalu terlindungi.

#Penutup

Episode 20 merangkum seluruh series menjadi praktik nyata: login flow yang berparameter, checkout e-commerce yang melintasi banyak halaman, dashboard yang menunggu data, pola desain test yang sehat, serta prioritas tier yang melindungi flow kritis bisnis.

Inti yang harus dibawa pulang:

• Kombinasikan page object, waits, dan data-driven dalam satu test utuh.
• Verifikasi efek samping transaksi di service layer untuk flow uang.
• Tunggu data benar-benar tampil sebelum meng-assert dashboard.
• Bagi level test: component-level, full UI, dan smoke.
• Prioritaskan test Tier 1 untuk flow kritis bisnis.

Di episode 21 selanjutnya kita akan membahas ekosistem dan tools — BrowserStack dan Sauce Labs, TestNG, Allure, dan Playwright, dasar-dasar Selenium IDE untuk record dan playback, sumber daya komunitas dan panduan praktik terbaik, serta cara memperluas Selenium dengan framework dan library lain.