Pengembang sering membuat kesalahan dengan menambahkan ID identik atau atribut data-* khusus ke objek UI yang berbeda. Daripada menunggu mereka memperbaiki masalahnya, mari kita buat penyeleksinya unik.

Pengembang sering membuat kesalahan dengan menambahkan ID identik atau atribut data-* khusus ke objek UI yang berbeda. Kebanyakan alat berasumsi bahwa ID dan atribut khusus adalah unik dan membuat pemilih berdasarkan hal ini. Artinya elemen pertama pemilih CSS adalah ID atau atribut khusus. Misalnya, pencarian Gmail di email:

dan pemilih CSS singkat yang dihasilkan oleh Google Inspector adalah:

Hal ini masuk akal karena semakin pendek pemilihnya, semakin stabil. Mari kita pertimbangkan pemilih panjang yang dimulai dari isi, yaitu dari awal:

badan > div:anak ke-n(25) > div.nH > div > div.nH.aqk.aql.bkL > div.aqn.aIH.nH.oy8Mbf.apV > div.aBO > div.aic > div > div

Jika ada bagian yang berubah, pemilihnya menjadi salah. Terutama bagian anak yang sering berubah, misalnya dari anak ke-n(25) ke anak ke-n(26)

Namun, seperti yang disebutkan, ID untuk elemen UI yang berbeda mungkin sama. Berikut ini contoh pemilihan tab untuk 'Persyaratan' dan 'Desain pengujian' di bawah sama yang dihasilkan oleh Google Inspector dan Harmony:

yaitu keduanya #tab-\:rf\:–tab-0 > hal

Dalam kasus ini, Anda dapat meminta pengembang untuk memperbaiki masalah pemilih, namun biasanya memerlukan waktu berhari-hari karena ini adalah masalah penguji, bukan masalah pengguna. Solusinya adalah dengan mengenali penyeleksi yang sama dan menetapkan alternatif yang berbeda. Dalam contoh kita Harmoni secara otomatis menghasilkan pemilih yang berbeda, yaitu tab Persyaratan memiliki pemilih:

[data-testid=”feature-editor”] > div > div:anak ke-n(2) > div:anak ke-n(2) > [data-testid=”split-view-view”]:anak-n(2) > div > div:anak-n(2) > [data-testid=”split-view-view”] > div > div:anak ke-n(2) > div:anak ke-n(1) > tombol > p

sedangkan tab Desain pengujian memiliki pemilih:

[data-testid=”feature-editor”] > div > div:anak ke-n(2) > div:anak ke-n(2) > [data-testid=”split-view-view”]:anak-n(1) > div > div:anak-n(2) > [data-testid=”split-view-view”] > div > div:anak-n(2) > div:anak-n(3) > tombol:anak-n(1) > p

Ini bukan solusi permanen karena penyeleksinya terlalu panjang, tetapi kasus uji berfungsi dengan baik hingga pengembang memperbaiki masalah ID.

Jika Anda tidak menggunakan Harmony, mari kita coba membuat pemilih duplikat dengan alat berbeda yang mungkin menghasilkan pemilih berbeda.

Perhatikan bahwa kerangka otomatisasi pengujian menawarkan untuk memaksa salah satu elemen UI dalam kasus ini, namun, bagi saya, ini rawan kesalahan dan paling tidak elegan.

Masalah lain dengan penyeleksi adalah nama mereka. Solusi pengkodean tradisional memerlukan pemberian nama yang bermakna untuk setiap pemilih dan menggunakan nama ini sebagai ganti pemilih. Dengan cara ini jika pemilih berubah, Anda dapat memodifikasinya di satu tempat. Namun, solusi ini memerlukan pengkodean tambahan. Pengujian berbasis model memerlukan lebih sedikit pekerjaan.

Harmony, misalnya, mencoba memberikan nama yang bermakna berdasarkan ID, atribut khusus, atau teks milik elemen UI. Misalnya, nama pemilih identik dengan atribut khusus 'tambahkan Coke':

Namun, mungkin saja tidak ada nama pemilih yang berarti yang dapat ditambahkan. Dalam hal ini, Anda harus mengubah nama agar bermakna. Misalnya pada aplikasi Glosarium ISTQB, atributnya hanya diberi nomor:

Anda dapat langsung memodifikasinya sehingga ketika pemilih berubah, Anda dapat dengan mudah mengenalinya:

Sekarang mudah untuk memilih atribut yang sesuai.