Saat menguji UI multibahasa Flutter, kami menemukan “300 BPM” terpisah menjadi dua baris
Kami menguji tampilan SANGE Metronome dengan memadukan 12 bahasa, 6 ukuran layar, dan 3 skala teks. Pemisahan “300 BPM” dan pesan kesalahan yang panjang mendorong perbaikan UI serta peninjauan pemeriksaan dalam pengujian otomatis.
Kami memeriksa tampilan pada layar kecil dan pengaturan teks besar di “SANGE Metronome – Latihan Ritme Sederhana”, aplikasi yang kami kembangkan secara independen.
Salah satu masalah yang ditemukan adalah angka “300 BPM” di favorit terpisah menjadi “30” dan “0”. Teks tersebut tidak keluar dari layar. Meski begitu, nilai temponya menjadi sulit dibaca.
Tidak adanya pengecualian tata letak dan keterbacaan informasi yang diperlukan harus diperiksa secara terpisah.
Artikel ini membahas masalah tampilan yang ditemukan melalui pengujian widget dalam 12 bahasa dan pemeriksaan layar pada emulator Android, serta bagaimana temuan tersebut diterapkan pada perbaikan dan pengujian.

Tata letak yang muat dalam bahasa Jepang belum tentu dapat digunakan dengan cara yang sama dalam bahasa lain
Layar metronom menampilkan bukan hanya angka tempo, melainkan juga ketukan, nama ritme, volume, dan nama favorit. Layar penyimpanan juga membutuhkan kolom input, penjelasan kesalahan, serta tombol Simpan dan Batal.
Meskipun tata letak muat saat diperiksa dalam bahasa Jepang, panjang label berubah setelah diterjemahkan. Misalnya, “12拍” dalam bahasa Jepang dan “12 Schläge” dalam bahasa Jerman membutuhkan lebar tombol yang berbeda.
Saat teks diperbesar, elemen yang semula berdampingan tidak lagi muat. Karena itu, kami tidak hanya mengganti bahasa, tetapi memutuskan untuk memadukan ukuran layar, skala teks, dan layar yang ditampilkan dalam pemeriksaan.
Verifikasi otomatis dengan 12 bahasa, 6 ukuran, dan 3 skala teks
Dalam pengujian widget, kami memadukan kondisi berikut. Pengujian widget merender komponen UI Flutter dalam lingkungan pengujian untuk memeriksanya.
| Aspek pemeriksaan | kondisi |
|---|---|
| Bahasa | Jepang, Inggris, Spanyol, Portugis Brasil, Jerman, Prancis, Korea, Indonesia, Vietnam, Thai, Tionghoa Tradisional, dan Italia |
| Ukuran logis, orientasi potret | 320×568、360×640、360×800、393×873、412×915、432×960 |
| Skala teks | 100%, 130%, dan 200% |
| Layar | Beranda, ketukan, subdivisi ritme, pengaturan, pemilihan bahasa, penyimpanan, pengelolaan favorit, dan daftar favorit |
12 bahasa × 6 ukuran × 3 skala teks × 8 layar = 1,728 kondisi
Data pengujian mencakup 300 BPM, 12 ketukan, not seperenam belas, volume 100%, serta tiga favorit dengan nama panjang. Pada layar penyimpanan, kami juga menampilkan kesalahan nama duplikat.
Skala teks ditentukan dengan TextScaler.linear. Nilai 100%, 130%, dan 200% dalam verifikasi ini merupakan kondisi pembesaran linear, bukan reproduksi menyeluruh dari semua bentuk pembesaran teks melalui pengaturan sistem pada perangkat nyata.
Kami juga mengumpulkan gambar melalui emulator Android dalam tujuh bahasa: Jerman, Prancis, Portugis Brasil, Indonesia, Thai, Vietnam, dan Jepang. Kami tidak mencoba seluruh kombinasi ukuran, skala, dan bahasa. Ukuran layar dan skala teks diperiksa dalam bahasa Jerman, sedangkan enam bahasa lainnya diperiksa dengan pengaturan 360×640 dan skala 130%.
Pada emulator, bilah sistem mengurangi area yang tersedia untuk aplikasi. Selain ukuran yang ditetapkan, kami mencatat ukuran logis saat render dan ukuran di dalam SafeArea.
Sesuaikan jumlah kolom tombol ketukan agar teks muat
Masalah pertama yang ditemukan adalah teks penjelasan tempo dan satuan ketukan yang melampaui sisi kanan. Emulator Android juga mendeteksi RenderFlex overflow, sehingga tata letaknya perlu ditinjau kembali.
Tombol pemilihan ketukan juga menggunakan empat kolom tetap. Namun, ketika label terjemahan menjadi lebih panjang atau skala teks meningkat, jumlah kolom tersebut tidak menyediakan lebar yang cukup.
Kami kemudian mengukur label hasil terjemahan dengan TextPainter dan menentukan jumlah kolom berdasarkan lebar yang diperlukan, termasuk skala teks. Pada kondisi sempit, jumlah kolom dikurangi dan tombol disusun secara vertikal.


Di beranda, kami juga meninjau susunan yang memaksakan nama ritme panjang ke dua kolom sempit, lalu menyusun ketukan dan ritme secara vertikal bila diperlukan. Untuk mengatasi pemisahan angka ketukan 10 hingga 12, seluruh kumpulan indikator ketukan dibuat dapat membungkus ke beberapa baris.
Terpisahnya “300” tidak selalu memicu pengecualian
Saat meninjau gambar, kami menemukan masalah pada kartu favorit dengan pengaturan 320×568 dan skala teks 200%.
Karena kartu tetap disusun dalam tiga kolom, “300” berganti baris di tengah angka. Meskipun teks muat di area tampilan, memisahkannya menjadi “30” dan “0” menyulitkan pembacaan nilai tempo.
Masalah ini tidak terdeteksi hanya dengan pemeriksaan pengecualian tata letak.
Perbaikannya menyesuaikan jumlah kolom kartu favorit dengan skala teks. Pada layar kecil dengan skala 200% dalam verifikasi ini, kami beralih ke satu kolom agar angka tempo tidak terpisah di tengah.

Bersama perbaikan ini, kami menambahkan pemeriksaan bahwa BPM tiga digit tetap berada pada satu baris ke pengujian otomatis. Berikut cuplikan bagian pemeriksaan tersebut.
for (var card = 0; card < 3; card++) {
final paragraph = tester.renderObject<RenderParagraph>(
find.text('300 BPM').at(card),
);
expect(
paragraph.getBoxesForSelection(
const TextSelection(baseOffset: 0, extentOffset: 3),
),
hasLength(1),
reason:
'$locale/$size/$scale favorite BPM must stay on one line',
);
}
Kami memastikan bahwa rentang karakter yang sesuai dengan “300” menempati satu kotak render. Dalam pengujian lengkap, kami memeriksa BPM masing-masing dari tiga favorit serta nomor ketukan 1 hingga 12 di beranda.
Metode ini ditujukan untuk angka yang dirender dengan jenis huruf yang sama dalam verifikasi ini. Metode ini bukan cara umum untuk menentukan pergantian baris pada teks yang mencampurkan bahasa atau jenis huruf yang berbeda.
Membuat pemeriksaan yang konkret sesuai informasi yang ingin ditampilkan. Salah satu hasil berharga kali ini adalah memasukkan masalah yang ditemukan melalui gambar ke pengujian otomatis agar dapat dideteksi lagi pada perubahan berikutnya.
Apakah penjelasan kesalahan dapat dibaca dan tombol Simpan dapat dijangkau?
Pada layar penyimpanan, kami juga meninjau batas jumlah baris pesan kesalahan.
Sebelumnya teks dibatasi hingga tiga baris, tetapi terjemahan panjang mungkin tidak muat pada layar sempit dengan teks besar. Kami menghapus batas jumlah baris agar seluruh penjelasan dapat dibaca dengan menggulir.
Tombol Simpan dan Batal diubah menjadi susunan vertikal pada layar sempit atau teks besar. Judul dan tombol tutup modal, serta nama pengaturan dan nilai yang dipilih, juga ditata ulang untuk menyediakan lebih banyak lebar bagi teks.

Kami juga menambahkan pemeriksaan saat mengetik. Dalam pengujian widget, kami menyediakan ruang bawah sebesar 280 piksel logis yang mewakili papan ketik dan memastikan tombol Simpan berada di atas area tersebut setelah pengguliran. Kami juga memastikan pesan kesalahan tidak terpotong oleh batas jumlah baris.
Di emulator Android, kami benar-benar memfokuskan kolom input dan memeriksa tata letak ketika papan ketik terbuka. Namun, PNG yang dikumpulkan saat itu hanya menangkap layar Flutter: papan ketik sistem sendiri tidak terlihat. Gambar tampilan normal dan saat mengetik dicatat secara terpisah.
Hasil setelah perbaikan dan cakupan yang diperiksa
Berikut hasil verifikasi pada 30 Oktober 2026.
| Barang | Hasil |
|---|---|
| Pengujian widget tampilan | Tidak ada pengecualian tata letak pada 1,728 kondisi. Pemeriksaan pemisahan angka, pemotongan pesan kesalahan, dan keterjangkauan tombol Simpan juga lolos pada layar terkait |
| Seluruh pengujian Flutter | 121 pengujian lolos |
| Analisis statis | Tidak ada temuan |
| Kondisi layar pada emulator Android | 280 kondisi. Pada setiap pelaksanaan, layoutErrors berjumlah 0 |
| PNG yang dikumpulkan | 478 gambar, termasuk setelah pengguliran dan saat mengetik |
1,728 adalah jumlah kombinasi kondisi tampilan, sedangkan 121 adalah jumlah keseluruhan pengujian Flutter yang dijalankan. Karena beberapa kondisi tampilan diperiksa berulang kali di dalam pengujian, kedua angka ini memiliki arti yang berbeda.
Angka 478 merupakan jumlah PNG yang dikumpulkan. Kami tidak memberikan penilaian visual lolos atau gagal pada setiap gambar; kami memilih layar utama untuk memeriksa karakter yang terpotong atau tumpang tindih, angka yang terpisah, serta tampilan setelah pengguliran. Pada layar utama bahasa Thai dan Vietnam yang diperiksa, kami tidak melihat kotak penanda karakter hilang ataupun teks yang tumpang tindih.
Selain enam ukuran sintetis, kami menggunakan enam pengaturan tampilan di emulator: Galaxy A16 5G, A06 4G, S24+, S23, Redmi 14C 4G, dan Pixel 9. Kami menyiapkan 30 pengaturan khusus model, tetapi hanya menjalankan enam di antaranya kali ini.
Kami menerapkan resolusi dan kepadatan perkiraan untuk pengujian pada emulator Android 14 yang sama. Kami tidak mereproduksi sistem khusus produsen, jenis huruf, atau lubang kamera, dan tidak menguji 30 model pada perangkat nyata. Pengujian Flutter dijalankan di Windows; perbandingan golden dengan kecocokan piksel untuk Linux juga tidak dijalankan kali ini.
Catatan ini membahas verifikasi tampilan. Hasil render, pemfokusan kolom input, dan pengguliran tidak membuktikan keberhasilan pemutaran audio ataupun proses penyimpanan.
Hal yang tetap perlu diperiksa pada perubahan UI berikutnya
Verifikasi ini memperjelas hal-hal yang ingin kami pertahankan dalam pengujian tampilan.
- Jangan memisahkan nilai numerik seperti tempo dan nomor ketukan di tengah angka.
- Pastikan seluruh penjelasan kesalahan dapat dibaca.
- Pastikan tombol yang diperlukan tetap terjangkau saat teks diperbesar dan saat mengetik.
Dengan menyesuaikan jumlah kolom terhadap ukuran teks dan terjemahan, serta memakai susunan vertikal dan pengguliran, kami menyediakan ruang bagi informasi dan operasi yang diperlukan.
Memeriksa kondisi secara berulang melalui pengujian otomatis dan menambahkan masalah yang terlihat pada gambar hasil render ke daftar pemeriksaan. Dengan mempertahankan alur ini, kami dapat memeriksa apakah masalah yang ditemukan kali ini muncul lagi saat UI diubah berikutnya.