Episode ini membahas data-driven testing: memakai parametrize untuk banyak test case, memisahkan input dan expected result, membaca data dari CSV, JSON, dan Excel, serta memperluas cakupan test ke banyak browser dan environment.

Menulis satu test untuk satu skenario itu mudah. Masalah muncul ketika skenario bertambah: validasi form dengan sepuluh kombinasi input, atau uji login dengan lima tipe akun. Menyalin test sepuluh kali adalah jalan menuju kekacauan. Episode 9 memperkenalkan data-driven testing — memisahkan data dari logika test sehingga satu test melayani banyak kasus.
Pendekatan ini bukan hanya mengurangi duplikasi, tapi juga membuat test lebih mudah diperbarui: ketika data berubah, kalian cukup memperbarui file data, bukan menulis ulang kode. Episode ini membahas parameterisasi dengan pytest, sumber data eksternal seperti CSV, JSON, dan Excel, serta memperluas cakupan ke banyak browser dan environment.
pytest menyediakan parametrize untuk menjalankan fungsi test yang sama dengan banyak set data:
import pytest
@pytest.mark.parametrize(
"email,password,harapan",
[
("user@example.com", "rahasia123", "Selamat datang"),
("salah@example.com", "salah", "Email atau password salah"),
("", "", "Kolom wajib diisi"),
],
)
def test_login(email, password, harapan):
halaman = LoginPage(driver)
halaman.isi_email(email)
halaman.isi_password(password)
halaman.klik_masuk()
assert harapan in halaman.ambil_pesan()@pytest.mark.parametrize(...) menghasilkan tiga test terpisah dengan nama yang menyertakan argumen. Ketika satu kasus gagal, pytest menampilkan kasus mana yang gagal dan data apa yang dipakai — persis yang kalian butuhkan untuk debugging.
Untuk banyak data, beri id agar laporan mudah dibaca:
@pytest.mark.parametrize(
"email,password,harapan",
[...],
ids=["login-berhasil", "login-salah", "field-kosong"],
)
def test_login_kasus(email, password, harapan):
...Parameter ids=["login-berhasil", "login-salah", "field-kosong"] mengganti nama kasus di output. Di CI, nama yang deskriptif ini membuat laporan kegagalan jauh lebih mudah dimengerti.
Data test sering hidup di luar kode agar bisa diubah oleh tim non-engineer. Membaca dari file JSON mudah:
import json
import pytest
def data_login():
with open("data/login_cases.json") as f:
return [(c["email"], c["password"], c["harapan"]) for c in json.load(f)]
@pytest.mark.parametrize("email,password,harapan", data_login())
def test_login_dari_json(email, password, harapan):
...Fungsi data_login() membaca daftar kasus dari JSON dan mengubahnya menjadi tuple untuk parametrize. Format file data juga mudah diubah dari CSV ke Excel tanpa mengubah logika test.
Untuk CSV, pakai module csv dari standard library; untuk Excel, library openpyxl:
pip install openpyxlSetelah pip install openpyxl, membaca sheet cukup dengan memuat workbook lalu iterasi baris. Pilih format berdasarkan kebutuhan tim: CSV paling ringan, JSON paling ekspresif, dan Excel paling ramah untuk tim non-teknis yang mengelola data.
Pasangkan input dengan expected result dalam satu tuple, seperti yang sudah kita lakukan. Pola ini punya dua keuntungan: test case menjadi lengkap (input plus ekspektasi), dan failure message menampilkan kedua sisi — input mana yang dipakai dan hasil apa yang diharapkan.
kasus = [
("Jakarta", "DKI Jakarta"),
("Surabaya", "Jawa Timur"),
("Bandung", "Jawa Barat"),
]Setiap baris ("Jakarta", "DKI Jakarta") adalah satu skenario utuh: ketik kota, cek provinsi yang muncul. Menjaga input dan ekspektasi berdekatan membuat data test bisa di-audit sekilas.
Data-driven bukan hanya untuk input — ini juga pola untuk memperluas jangkauan test:
@pytest.mark.parametrize("browser", ["chrome", "firefox", "edge"])
def test_beranda(browser, buat_driver):
driver = buat_driver(browser)
driver.get("https://example.com")
assert "Example" in driver.title@pytest.mark.parametrize("browser", ["chrome", "firefox", "edge"]) menjalankan test yang sama di tiga browser. Kombinasi dengan parameter environment (staging, production) menghasilkan matriks test yang menyeluruh tanpa menulis satu baris tambahan per kombinasi.
Tip
Jangan meng-parameterisasi segalanya. Jika suatu kasus butuh langkah setup yang sangat berbeda, pisahkan menjadi test terpisah — parameterisasi yang dipaksakan justru membuat test sulit dibaca.
Episode 9 membuat suite kalian bisa tumbuh tanpa menggandakan kode: satu fungsi test melayani banyak kasus lewat parametrize, data disimpan terpisah di JSON, CSV, atau Excel, dan matriks browser plus environment diperluas hanya dengan menambah parameter.
Inti yang harus dibawa pulang:
parametrize menjalankan satu test dengan banyak set data.ids agar laporan kegagalan mudah dibaca.Di episode 10 selanjutnya kita akan membahas Selenium Grid dan parallel execution — mengonfigurasi grid lokal, menjalankan test paralel di banyak browser, memakai Docker-based grid dan remote WebDriver, serta mengelola node dan session load.